On Wed, 2006-03-29 at 17:28 +0200, Florian Schmidt wrote: > > > > [ 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. > Doesn't this trace mean the problem is that jamin actually crashed and dumped core on exit? Lee
