[lkml]   [2001]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Questionable SIGSEGV signal handling bug concerning siginfo.si_addr on i386-linux 2.4.2
    Hugo Mildenberger wrote:
    > Dear friends,
    > I'm working on a library, which is able to map (at least synchronous) kernel
    > signals to c++ exceptions in a way, that c++ exception handlers can
    > determine reason and location of failure in a very detailed manner. Within
    > that context, I detected a surprising difference in the behaviour of my test
    > programs, depending on if they have been compiled by gcc-2.9.2 or gcc-3.0.
    > When I compiled the program with gcc-3.0, siginfo.si_addr contained an
    > address, which was always by a value of +4 too large when compared to the
    > original invalid pointer value (e.g.0x1238 versus 0x1234 or 0x4 versus 0x0).
    > By contrast, the gcc-2.9.2 compiled program behaved correctly.
    > That symptom, as I thought, may have been caused by a subtile processor bug,
    > which depends on register usage or instruction ordering. And I tracked it
    > down to the following difference in offending instructions (both are located
    > in the same routine of my test program and causing the expected SIGSEGV,
    > suppose eax would contain a value of 0x1234):
    > ->gcc-2.95.2: 807c38a: dd 00 fldl (%eax)
    > ->gcc-3.0: 806e457: 8b 70 04 mov 0x4(%eax),%esi
    > siginfo.si_addr contained a correct value in the first case, but an offset
    > of +4 compared to the original eax value in the second case.

    What you are seeing is the correct behavior. The address in si_addr is
    the exact address that caused the page fault (from register %cr2). It
    appears that you were trying to access an element of a structure, where
    the structure pointer was in %eax and the offset of the element within
    the structure is 4 bytes. I suggest that if you are trying to find out
    if a fault happened inside a structure you check the whole range of
    addresses in that structure, because any of them could have faulted.


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

     \ /
      Last update: 2005-03-22 12:55    [W:6.993 / U:0.420 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site