29 Mar
2006
29 Mar
'06
4:31 p.m.
On Wed, 2006-03-29 at 17:28 +0200, Florian Schmidt wrote:
Doesn't this trace mean the problem is that jamin actually crashed and
dumped core on exit?
Lee
[ 4797.602341] jamin:17931 userspace BUG: scheduling in user-atomic
context!
[ 4797.602362] [<c01049f5>] show_trace+0x25/0x30 (20)
[ 4797.602382] [<c0104a23>] dump_stack+0x23/0x30 (20)
[ 4797.602395] [<c02bfa64>] schedule+0x114/0x140 (36)
[ 4797.602412] [<c02bfda4>] wait_for_completion+0xa4/0xe0 (48)
[ 4797.602426] [<c017bb68>] do_coredump+0x348/0x780 (192)
[ 4797.602456] [<c012edf1>] get_signal_to_deliver+0x391/0x510 (60)
[ 4797.602473] [<c0102c68>] do_notify_resume+0xb8/0x75c (220)
[ 4797.602486] [<c01034fc>] work_notifysig+0x13/0x1b (-8116)
[ 4797.602498] ---------------------------
[ 4797.602504] | preempt count: 00000000 ]
[ 4797.602511] | 0-level deep critical section nesting:
[ 4797.602518] ----------------------------------------
What does that mean?
This gives you a clue about what system call/code path in the kernel
caused the volountary giving up of cpu.
To find out what the app did to produce this behaviour, build the app
with debug symbols, and eiter run it in gdb or do ulimit -c unlimited
and examine the core after the app got terminated (it will dump a
core)
with gdb.