From mboxrd@z Thu Jan 1 00:00:00 1970 From: sboisvert@gydle.com (Sebastien Boisvert) Date: Tue, 16 Apr 2019 14:21:50 -0400 Subject: [lttng-dev] SIG33 message In-Reply-To: <56684942.2314.1555438313423.JavaMail.zimbra@efficios.com> References: <03778ce1-f017-176a-3c5f-35fba359b5aa@gydle.com> <56684942.2314.1555438313423.JavaMail.zimbra@efficios.com> Message-ID: <91e63721-14c2-74f8-66ac-fec45ae8721f@gydle.com> 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 ? [1] http://man7.org/linux/man-pages/man7/signal.7.html [snip]