RE: Kernel 4.9.x-rt Fully Preemptible Kernel: Issue with gdb and unexpected SIGSTOP signals

["Koehrer Mathias (ETAS/ESW3)" <mathias.koehrer@etas.com>]

Hi Sebastian,

thanks for the feedback.
> > In the error case, there is "prev_state=T|K".
> 
> The t|K should be okay.
> 
>         gdb-issue-8145  [001] .......  9315.877956: sched_process_fork: comm=gdb-
> issue pid=8145 child_comm=gdb-issue child_pid=8473
>         gdb-issue-8145  [001] d...2..  9315.877958: sched_wakeup_new: comm=gdb-
> issue pid=8473 prio=39 target_cpu=001
>         gdb-issue-8145  [001] d...212  9315.877964: sched_wakeup: comm=gdb
> pid=8138 prio=120 target_cpu=004
>         gdb-issue-8145  [001] .....12  9315.877964: signal_generate: sig=17 errno=0
> code=262148 comm=gdb pid=8138 grp=1 res=0
>         gdb-issue-8145  [001] d...2..  9315.877966: sched_switch: prev_comm=gdb-
> issue prev_pid=8145 prev_prio=39 prev_state=t|K ==> next_comm =gdb-issue
> next_pid=8473 next_prio=39
>            <idle>-0     [004] d...2..  9315.877990: sched_switch: prev_comm=swapper/4
> prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=gdb  next_pid=8138
> next_prio=120
>               gdb-8138  [004] .......  9315.877992: sys_exit: NR 7 = -516
>               gdb-8138  [004] .....11  9315.877993: signal_deliver: sig=17 errno=0
> code=262148 sa_handler=5623f7c281e0 sa_flags=14000000 …
> 
> The gdb task deals with each new child and releases it later:
> 
>               gdb-8138  [004] .......  9315.878159: sys_enter: NR 101 (11, 2119, 0, 0, 10,
> 30)
>               gdb-8138  [004] d...2..  9315.878160: sched_wait_task: comm=gdb-issue
> pid=8473 prio=39
>               gdb-8138  [004] d...212  9315.878163: sched_wakeup: comm=gdb-issue
> pid=8473 prio=39 target_cpu=001
>               gdb-8138  [004] .......  9315.878164: sys_exit: NR 101 = 0
> 
> later it is gone. So that looks fine. When it hangs
> 
>         gdb-issue-8424  [000] d...212  9315.738204: sched_wakeup: comm=gdb
> pid=8138 prio=120 target_cpu=004
> (8424 will sched out due to ptrace)
>               gdb-8138  [004] .......  9315.738207: sys_exit: NR 61 = 8424
>               gdb-8138  [004] .......  9315.738214: sys_enter: NR 15 (c, 5623f7fff84b, 1,
> 0, 8, 30)
>               gdb-8138  [004] .......  9315.738215: sys_exit: NR -1 = 8424
>               gdb-8138  [004] .......  9315.738216: sys_enter: NR 101 (11, 20e8, 0, 0, 10,
> 30)
>               gdb-8138  [004] d...2..  9315.738217: sched_wait_task: comm=gdb-issue
> pid=8424 prio=39
>               gdb-8138  [004] d...112  9315.738218: sched_waking: comm=gdb-issue
> pid=8424 prio=39 target_cpu=000
>               gdb-8138  [004] d...212  9315.738220: sched_wakeup: comm=gdb-issue
> pid=8424 prio=39 target_cpu=000
>               gdb-8138  [004] .......  9315.738221: sys_exit: NR 101 = 0
>         gdb-issue-8144  [000] .......  9315.738246: sys_exit: NR 56 = 8424
>         gdb-issue-8144  [000] .......  9315.738261: sched_process_wait: comm=gdb-
> issue pid=8424 prio=39
> 
> and 8144 blocks in wait for 8424 which is never completes without additional help
> (like a manual SIGCONT). Right now it looks like the PTRACE_DETACH (syscall
> 101, 11) which should remove the task from ptrace and wakeup did not work but I
> see a wakeup… The wakeup worked (most likely) but since it is stuck I guess that
> there was a second signal it is processing and waiting for gdb.
I do not understand, what that means.
When I run the very same test on a non-rt kernel (or even on a RT kernel with a 
preemption model that is not configured as "Fully Preemptible Kernel"), I never see 
this issue.
Also - as mentioned - previously, with older RT preempted kernel versions it is working fine
as well. For me it looks as if the RT preempting on newer kernels somehow has impact 
on the way the debugging with gdb works
My expectation (and so far I had the experience) is that a code that is running fine 
with a non RT kernel should also run fine with the fully preempted kernel (of course 
the timing behavior is different). 

Regards

Mathias