[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.021 / U:60.856 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site