This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/20853] raise in catch_segfault supresses kernel messages for segfaults under libSegFault.so in Linux
- From: "gjc at alum dot mit.edu" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 01 Dec 2016 00:24:07 +0000
- Subject: [Bug libc/20853] raise in catch_segfault supresses kernel messages for segfaults under libSegFault.so in Linux
- Auto-submitted: auto-generated
- References: <bug-20853-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=20853
George J Carrette <gjc at alum dot mit.edu> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gjc at alum dot mit.edu
--- Comment #2 from George J Carrette <gjc at alum dot mit.edu> ---
Created attachment 9680
--> https://sourceware.org/bugzilla/attachment.cgi?id=9680&action=edit
adds new environment variable options to libSegFault.so
This is my test plan. The point of the plan is to show that
the new features enable libsegfault to be used in combination
with the operating system kernel syslog messages
reporting segfault events.
In one terminal window observe the kernel messages, e.g
sudo tail -f /var/log/messages
In another window, you must have a program that is able to create
faults. I have such a program that can do a simple segfault, causing
different kernel messages.
dofault0 segfault
causes
dofault0[54022]: segfault at 0 ip 0000000000400e86 sp 00007fffffffe2f0 error 4
in dofault0[400000+3000]
dofault0 illegal
causes
traps: dofault0[54023] trap invalid opcode ip:400a2a sp:7fffffffe2f8 error:0 in
dofault0[400000+3000]
dofault0 stackwipeout
causes
kernel: [10227008.852358] traps: dofault0[54041] general protection ip:4010ad
sp:7fffffffe088 error:0 in dofault0[400000+3000]
But to test these you do not need that fancy utility (which I shall publish
later if there is interest), instead you could use siod (scheme in one defun)
from some of the earliest versions having
siod "(%%%memref 0)"
causes
siod[54101]: segfault at 0 ip 00007ffff7bcb8e9 sp 00007fffffffdd70 error 4 in
libsiod.so[7ffff7bae000+2b000]
siod "(%%%memref -1)"
causes
siod[54102]: segfault at ffffffffffffffff ip 00007ffff7bcb8e9 sp
00007fffffffdd70 error 5 in libsiod.so[7ffff7bae000+2b000]
So here is the A/B test:
(A) standard existing behavior not using the enhancements
env LD_PRELOAD=/usr/local/lib/libSegFault.so siod "(%%%memref 0)"
You get the nice register dump and stack backtrace, but you do not
get anything in /var/log/messages
(B) utilize the new features:
env SEGFAULT_SA_RESETHAND_FLAG=1 SEGFAULT_NO_RAISE_IN_HANDLER=1
LD_PRELOAD=/usr/local/lib/libSegFault.so siod "(%%%memref 0)"
Then you will see the expected result in /var/log/messages
as if the LD_PRELOAD never happened.
Now you might object and say that the problem is with the version of
GNU Linux that I am using (Centos) or some kernel configuration.
But I have been using CentOS 7.1 fresh download with no modifications.
I will see what happens with the Ubuntu distribution, and am open
to suggestions to try in other operating system kernels using glibc.
However, the env SEGFAULT_SA_RESETHAND_FLAG=1 option is a solid
option to have in any case, unless you want to move the
SIG_DFL code to the start of the catch_segfault function.
--
You are receiving this mail because:
You are on the CC list for the bug.