[lttng-dev] SIG33 message
Mathieu Desnoyers
mathieu.desnoyers at efficios.com
Tue Apr 16 14:41:46 EDT 2019
----- On Apr 16, 2019, at 2:21 PM, Sebastien Boisvert sboisvert at gydle.com wrote:
> On 2019-04-16 2:12 p.m., Mathieu Desnoyers wrote:
> [snip]
>>
>> Hi Sebastien,
>>
>> This part of the ring buffer should only be used by the consumer daemon through
>> liblttng-ust-ctl.so, never from the traced applications.
>>
>> So I keep suspecting that it's NPTL's use of SIG33 which is causing an old
>> version of gdb to trap, ref:
>> https://gdb.sourceware.narkive.com/SzqG56iA/program-received-signal-sig33-real-time-event-33
>>
>> Thanks,
>>
>> Mathieu
>>
>
> If it is the case that an old gdb is involved,
> then it is unrelated to this kill() call site in the LTTng-UST source code:
>
> libringbuffer/ring_buffer_frontend.c:767: kill(getpid(),
> LTTNG_UST_RB_SIG_TEARDOWN);
>
> because LTTNG_UST_RB_SIG_TEARDOWN is SIGRTMIN + 2. According to the man page of
> signal(7) [1],
> SIGRTMIN is 34 (Native Posix Thread Library) or 35 (LinuxThreads, whatever that
> is).
>
>
> The equation
>
> 33 = SIGRTMIN + 2
>
> is not satisfied with either 34 or 35.
>
>
> So, is upgrading gdg the solution ?
Based on the gdb forum link I showed, either explicitly disable handling
SIG33 in older gdb:
handle SIG33 nostop noprint pass
or upgrade gdb.
Thanks,
Mathieu
>
>
> [1] http://man7.org/linux/man-pages/man7/signal.7.html
>
>
> [snip]
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
More information about the lttng-dev
mailing list