Messages in this thread |  | | | Date | Mon, 1 Mar 1999 11:20:02 -0500 (EST) | | From | "Richard B. Johnson" <> | | Subject | Re: 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).
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/
|  |