[lkml]   [1999]   [Mar]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.2.1: memory corruption and SIGSEGV handlers.
On Mon, 1 Mar 1999, Tigran Aivazian wrote:

> Hi guys,
> Below is a simple program that does this:
> 1. Registers a handler for SIGSEGV using sigaction(2) with no special
> flags.
> 2. Causes the first SIGSEGV to be sent by *(int *)0 = 0;
> 3. Inside the handler prints something and does *(int *)0 = 0;
> This results in a recursive invocation of the handler, which is
> reasonable.
> However, there are two problems I personally see here:
> a) eventually, the program hangs (presumably when we run out of user
> stack)

I don't see the program hanging. Instead, I see it looping, using
about 50% of the available CPU. It is still responsive to ^C, etc.
This is what I would expect because you are trying to produce a
double-fault and the kernel won't let you do this. However, you
have prevented the kernel from using its normal fault-handler, so
what would you expect? The program appears to perform exactly
as coded. If there is no signal-stack, you don't get a signal.
You deliberately used your signal stack via recursion and you
have no trap to force an exit so what you see is what you get.

> b) if you, additionally do something like ulimit -sH 1 before running the
> program, it causes some memory (page cache?) corruption (i.e. next time
> you run gcc(1) to compile something you get Internal error: signal 11
> stuff).

This doesn't happen here (I formatted the output a bit better).

7340: signal 11 (stack=0xbf803600)
7340: signal 11 (stack=0xbf803518)
7340: signal 11 (stack=0xbf803430)
7340: signal 11 (stack=0xbf803348)
7340: signal 11 (stack=0xbf803260)
7340: signal 11 (stack=0xbf803178)
7340: signal 11 (stack=0xbf803090)
7340: signal 11 (stack=0xbf802fa8)
7340: signal 11 (stack=0xbf802ec0)
7340: signal 11 (stack=0xbf802dd8) <====== waits forever after this.

> This is clearly wrong so someone should have a look at the different code
> paths corresponding to signal delivery in the case of kill(2) and via GP
> fault (trap handler). (i.e. if I replace *0 = 0 with kill(getpid(),
> SIGSEGV) everything is ok).

Dick Johnson
Penguin : Linux version 2.2.2 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.
Wisdom : It's not a Y2K problem. It's a Y2Day problem.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:50    [W:0.045 / U:64.216 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site