Hi Sebastian and Mathias,
I wanted to follow-up on this thread since we, too, are seeing issues with GDB and v4.9-rt kernels. We've been working on upgrading our systems/application from the v3.18-rt kernel series (specifically v3.18..29-rt30) to v4.9-rt (specifically 4.9.13-rt11) and immediately started experiencing various GDB related issues. The first (inability to pause at breakpoints and single-step) was eliminated by reverting to using GDB v7.11.1 (from GDB v7.12.1). However, the second (the SIGSTOP issue originally reported by Mathias) isn't something we've been able to work around. Have either of you made any of your own progress on this issue? Are others also seeing this?
Toolchain (v3.18-rt i386 targets/application)
GCC v4.9.3
GLIbC v2.19
GDB v7.11.1
Toolchain (v4.9-rt i386 targets/application)
GCC v4.9.4
GLibC v2.25
GDB v7.11.1
Thanks,
-David Hauck
NetAcquire Corp.
On Tuesday, March 07, 2017 3:22 PM, linux-rt-users-owner@xxxxxxxxxxxxxxx wrote:
> On 2017-03-07 13:39:36 [+0000], Koehrer Mathias (ETAS/ESW3) wrote:
>> Hi Sebastian,
> Hi Mathias,
>
>>> 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.
>
> I can reproduce the issue on a -RT kernel. I don't really know what the root issue is but it is a problem.
> We had a ptrace issue if you look into the queue for
> "ptrace: fix ptrace vs tasklist_lock race"
>> 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).
>
> That is correct - it should work. I've been tracing it for a while now and have no real clue what goes
> wrong. There a few different ways how it seems to go wrong and the outcome is always that the kernel
> puts the task in "stop" mode while gdb expects it to run and waits for it.
>
>> Regards
>>
>> Mathias
>
> Sebastian
��.n��������+%������w��{.n�����{�����ǫ���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
