8000 native uart0 crashes when no real terminal is attached · Issue #270 · RIOT-OS/RIOT · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

native uart0 crashes when no real terminal is attached #270

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
benpicco opened this issue Oct 26, 2013 · 14 comments
Closed

native uart0 crashes when no real terminal is attached #270

benpicco opened this issue Oct 26, 2013 · 14 comments
Assignees
@LudwigKnuepfer
Labels
Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)

Comments

@benpicco
Copy link
Contributor

A native RIOT process crashes when can't access real terminal input, e.g. when running it in the background and redirecting the output with >

running in gdb produces

(gdb) run tap0 < log.txt
Starting program: /home/benpicco/µkleos/virtual_network/node/bin/olsr_node.elf tap0 < log.txt
RIOT native interrupts/signals initialized.
RIOT native uart0 initialized.
LED_GREEN_OFF
LED_RED_ON
RIOT native board initialized.
RIOT native hardware initialization complete.

kernel_init(): This is RIOT!
Scheduler...[OK]
kernel_init(): jumping into first task...
uart0_init() [OK]
native rtc initialized
rtc_enable
rtc_enable
Initializing transport layer packages. Size of socket_type: 177
UART0 thread started.
lowpan_transfer: trying to get mutex. val: 0
atomic_set_return
lowpan_transfer: unlocking mutex. val: 1 pid: 10
olsr_snd: trying to get mutex. val: 0
atomic_set_return
olsr_snd: trying to get mutex. val: 0
atomic_set_return
olsr_snd: unlocking mutex. val: 1 pid: 12
olsr_snd: trying to get mutex. val: 0
atomic_set_return
olsr_snd: trying to get mutex. val: 1
atomic_set_return
olsr_snd: Mutex in use. 1
olsr_snd: Adding node to mutex queue: prio: 14
tcp_general_timer: trying to get mutex. val: 0
atomic_set_return
tcp_general_timer: unlocking mutex. val: 1 pid: 5
_native_set_uart_fds_native_lpm_sleep: returned: 1
_native_handle_uart0_input
_native_set_uart_fds_native_lpm_sleep: returned: 1
_native_handle_uart0_input
_native_set_uart_fds_native_lpm_sleep: returned: 1
_native_handle_uart0_input
_native_set_uart_fds_native_lpm_sleep: returned: 1
_native_handle_uart0_input
_native_set_uart_fds_native_lpm_sleep: returned: 1
[…]
_native_handle_uart0_input
_native_set_uart_fds_native_lpm_sleep: returned: 1
_native_handle_uart0_input
_native_set_uart_fds_native_lpm_sleep: returned: 1
_native_handle_uart0_input
uart0: unlocking mutex. val: 1 pid: 2
olsr_snd: waking up waiter.
olsr_snd: unlocking mutex. val: 1 pid: 12
_native_set_uart_fds_native_lpm_sleep: returned: 1
_native_handle_uart0_input

Program received signal SIGSEGV, Segmentation fault.
0x00000001 in ?? ()
(gdb) bt
#0  0x00000001 in ?? ()
#1  0x0808bc38 in runqueues ()
#2  0x080830a8 in sender_thread_stack ()
#3  0x08076a18 in __isr_stack ()
#4  0x08049f32 in restoreIRQ (state=1) at irq_cpu.c:233
#5  0x08066f15 in mutex_unlock (mutex=0x8082bd0 <sender_thread_stack+6896>) at mutex.c:114
#6  0x08066936 in hwtimer_releasemutex (mutex=0x8082bd0 <sender_thread_stack+6896>) at hwtimer.c:52
#7  0x08066923 in multiplexer (source=134763008) at hwtimer.c:48
#8  0x0804a820 in cpu_switch_context_exit () at native_cpu.c:121
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Executing the executable in a normal terminal works without issues. (And doesn't spew all the _native_set_uart_fds_native_lpm_sleep: returned: 1 - logging the output just for a few seconds causes several MB of those when compiling with -DENABLE_DEBUG)
@LudwigKnuepfer
Copy link
Member

You cant safely read input from a file at the moment, the upcoming #161 resolving PR changes that.
Apart from that I guess the problem is not the redirection but that the input which is coming too fast for the still unsafe context switches.

@ghost ghost assigned LudwigKnuepfer Oct 26, 2013
@LudwigKnuepfer
Copy link
Member

https://github.com/RIOT-OS/boards/pull/34

@LudwigKnuepfer
Copy link
Member

Although file input is still not properly supported (seems to work a bit though), this should fix the segfault.

@benpicco
Copy link
Contributor Author

It's not really file input, the file is empty (should rather have used /dev/null), but that was the only way I could get to run it in gdb,

echo r tap0 | gdb ./bin/olsr_node.elf

also triggers the issue, but gdb immediately exits afterwards.

(gdb) run tap0 < /dev/null

allows you to get the backtrace from above.
I've tried RIOT-OS/boards#34 but the problem persists.

@LudwigKnuepfer
Copy link
Member

I can't reproduce this with default-native.

@LudwigKnuepfer
Copy link
Member

Sorry, I can, but only with echo r tap0 | gdb ..

@LudwigKnuepfer
Copy link
Member

Sorry, again, I've got the error now ;-)

@LudwigKnuepfer
Copy link
Member

OK, the remaining error is indeed due to file io not being supported, I've added preliminary support for EOF in the PR.

@LudwigKnuepfer
Copy link
Member

By the way - why are you using uart in the first place if you are not using it?

@benpicco
Copy link
Contributor Author

It's required by sixlowpan because of bordermultiplex.c/border.c
But I'm not using that feature, there is just no way to compile it without that.

@benpicco
Copy link
Contributor Author
8000 benpicco commented Oct 26, 2013

Well with that it will shutdown straight away, that's not very desirable. It doesn't even allow the application to free it's resources, leaving the tap devices in a busy state.

./bin/olsr_node.elf tap1 > /tmp/log.txt &

output in log.txt is

RIOT native interrupts/signals initialized.

@LudwigKnuepfer
Copy link
Member

I guess whether a shutdown is desired is arguable... One case I had in mind was scripting shell commands.

@LudwigKnuepfer
Copy link
Member

I updated the PR according to your use case as you're probably the only user of this feature at the moment.

@LudwigKnuepfer
Copy link
Member

fixed by RIOT-OS/boards#34

CW-75 added a commit to CW-75/RIOT that referenced this issue Jul 1, 2022
@CW-75
Merge pull request RIOT-OS#270 from eduazocar/feature/test/border_router
7b6a959 
test/border_router: fixed with the new modifications
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@LudwigKnuepfer LudwigKnuepfer

Labels
Type: bug The issue reports a bug / The PR fixes a bug (including spelling errors)
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@benpicco @LudwigKnuepfer
0