[Bug libc/20853] New: raise in catch_segfault supresses kernel messages for segfaults under libSegFault.so in Linux

["gjc at alum dot mit.edu" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=20853

            Bug ID: 20853
           Summary: raise in catch_segfault supresses kernel messages for
                    segfaults under libSegFault.so in Linux
           Product: glibc
           Version: 2.17
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: gjc at alum dot mit.edu
                CC: drepper.fsp at gmail dot com
  Target Milestone: ---

I have observed under CentOS Linux release 7.1.1503 (Core)
that using env LD_PRELOAD=/lib64/libSegFault.so 
results in suppression of the messages from the kernel
that you normally expect in /var/log/messages e.g.

kernel: [9505035.171649] dofault0[29621]: segfault at 0 ip 0000000000400e86 sp
00007fffffffe360 error 4 in dofault0[400000+3000]

I have observed that the call to raise(signal) in glibc-2.24/debug/segfault.c
catch_segfault is not needed, at least for SIGSEGV and when you comment out
that call to raise the behavior of libSegfault.so is satisfactory,
performing to all expectations of
(a) printing the expected information to stderr
(b) causing the kernel to print the segfault message to syslog.
(c) causing the kernel to continue on with core dump handling.

Since these behaviors may vary according to operating system kernel
and possibly kernel configuration and settings,
I am suggesting that skipping the call to raise be an enhancement
modulated by a SEGFAULT_SKIP_RAISE_SIGNAL flag.

Perhaps in some operating environments that call to raise(signal) inside
the signal handler is needed.

-- 
You are receiving this mail because:
You are on the CC list for the bug.