Re: 2.2.1: memory corruption and SIGSEGV handlers.

Richard B. Johnson (root@chaos.analogic.com)
Mon, 1 Mar 1999 11:20:02 -0500 (EST)


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).

Cheers,
Dick Johnson
***** FILE SYSTEM WAS MODIFIED *****
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/