Re: [Xenomai] Xenomai 3: smokey test sched_tp causes oops when run in gdb

[Jan Kiszka <jan.kiszka@siemens.com>]

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