On 2015-03-16 15:43, Philippe Gerum wrote: > On 03/11/2015 03:47 PM, Jan Kiszka wrote: >> Hi Philippe, >> >> just happened to trigger the oops below by running >> >> gdb --args smokey --run=8 >> >> That run already has troubles and generates different output than >> running the test without gdb surveillance, probably due to unexpected >> mode switches. > > Clearly, yes. GDB causes the test program to leave primary mode, which > changes the scheduling order, and therefore the output which depends on it. > > But the real problem is that running the test again >> afterwards, with or without gdb, causes the oops. Registers contain >> suspicious "dead" patterns, thus we access invalid list elements. Do we >> miss a cleanup when terminating smokey in the gdb session? >> > > I could not reproduce this bug yet. > > There is no reason for ptracing the application to have any impact on > the housekeeping chores when it exits. The backtrace shows that > xnsched_tp_set_schedule() is walking through tp->threads, which seems to > link to a stale tcb. xnsched_tp_forget() would then be called twice, > leading to the fault. > > Normally, a thread that undergoes TP scheduling should be automatically > removed from tp->threads upon exit after this sequence took place: > > handle_taskexit_event -> __xnthread_cleanup -> cleanup_tcb -> > xnsched_forget -> xnsched_tp_forget > > For that bug to happen, either this assumption has to be wrong, or > xnsched_set_policy() is being silly at some point. > > Is this 100% reproducible on your end, and does this require the initial > gdb run to show up, or would that break even when running the sched_tp > twice without gdb?
It is always reproducible, also with current next branch. And you need to run gdb beforehand, yes. I'll see if I can look into details. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux _______________________________________________ Xenomai mailing list Xenomai@xenomai.org http://www.xenomai.org/mailman/listinfo/xenomai
