[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