This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 140837 - Signal handling inside signal handler changed between 2.4 and 2.6
Signal handling inside signal handler changed between 2.4 and 2.6
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Roland McGrath
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-25 08:04 EST by Johan Walles
Modified: 2007-11-30 17:07 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-12-04 18:55:43 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Repro case (3.42 KB, text/plain)
2004-11-25 08:05 EST, Johan Walles
no flags Details

  None (edit)
Description Johan Walles 2004-11-25 08:04:33 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; sv-SE; rv:1.6) Gecko/20040113

Description of problem:
When JRockit crashes, it attempts to print a textual crash dump in
addition to dumping a core file.  This crash dump contains (among
other things) hex dumps of the stack and the code around the IP.

To prevent JRockit from crashing when dumping those regions, a SIGSEGV
handler is set up around the dangerous memory accesses.  If they are
inaccessible, they are simply excluded from the crash dump.

The crash protection code works fine on all 2.4 based systems I have
tried it, and it breaks on all 2.6 based systems I have tried it
(ia32, ia64, amd64).

I'll attach the reproducer, please bug me if I forget.


Version-Release number of selected component (if applicable):
Linux version 2.6.8-1.528.2.10smp (bhcompile@tweety.build.redhat.com)
(gcc version 3.4.1 20040815 (Red Hat 3.4.1-9)) #1 SMP Wed Sep 1
03:49:31 EDT 2004


How reproducible:
Always

Steps to Reproduce:
./badptrprotection

Actual Results:  Before setting up signal handlers: 0x7 is not accessible
After setting up signal handlers: 0x7 is not accessible
Received signal 11
From within the altstack SIGSEGV handler: Segmentation fault


Expected Results:  Before setting up signal handlers: 0x7 is not
accessible
After setting up signal handlers: 0x7 is not accessible
Received signal 11
From within the altstack SIGSEGV handler: 0x7 is not accessible


Additional info:
Comment 1 Johan Walles 2004-11-25 08:05:49 EST
Created attachment 107457 [details]
Repro case
Comment 2 Johan Walles 2004-11-25 08:22:18 EST
As another data point, if I run this in gdb and just do "c"ontinue at
every SIGSEGV, gdb finally says:

...
(gdb)
Continuing.
Received signal 11
From within the altstack SIGSEGV handler:
Program received signal SIGSEGV, Segmentation fault.
0x080487d3 in isBadReadPtr (ptr=0x7, size=0x4) at badptrprotection.c:68
68            n += *(unsigned char *)ptr++;
(gdb)
Continuing.
Couldn't get registers: No such process.
Comment 3 Dave Jones 2004-11-30 19:26:08 EST
did this get fixed in b2 ?
Comment 4 Johan Walles 2004-12-01 04:15:04 EST
Apparently we don't have any b2 boxes over here, and since the RC
seems to be only two weeks away we might want to wait until then to
upgrade our b1 box.

It would be nice if you could try the attached repro case on one of
your b2 boxes; it shouldn't take you more than a couple of minutes.

In case you're unable to do that, I'll try again once the RC arrives.
Comment 6 Jason Baron 2004-12-01 14:36:37 EST
attached test case still fails on b2...
Comment 8 Roland McGrath 2004-12-02 17:15:38 EST
The 2.6 behavior here has indeed changed from what 2.4 did.
However, this is only in a case that is undefined behavior according to POSIX.
The issue is what happens when a SIGSEGV is generated by a memory fault,
while SIGSEGV is already blocked.  POSIX says this case is undefined.
In 2.4, the signal is simply unblocked and then delivered normally; and,
if the signal had been ignored (set to SIG_IGN) then and only then its handler
is reset to SIG_DFL before delivery (meaning the program dies rather than
running a handler).  In 2.6, if the signal is either blocked or ignored, then it
is both unblocked and reset to SIG_DFL.  The upstream change logs indicate this
was an intentional change by Linus, though I am not entirely convinced it's
necessary for the stated goals.

The user program can avoid the problem in a way that will work the same on 2.4
and 2.6, and which relies only on behavior explicitly specified by POSIX.
That is, the outer signal handler for SIGSEGV, that then tries to provoke
another SIGSEGV, should unblock SIGSEGV (using sigprocmask) before it might
produce a second SIGSEGV.
Comment 10 Roland McGrath 2004-12-04 18:55:43 EST
We expect the 2.6 behavior to stand.  Applications can adapt by changing to rely
only on standard behavior.  That is, unblock SIGSEGV in the handler before
provoking it a second time.
Comment 11 Johan Walles 2004-12-06 03:01:20 EST
FWIW unblocking the signal handler before triggering it a second time worked
fine.  Thanks for the feedback :-).

Note You need to log in before you can comment on or make changes to this bug.