debugging question

Discussion in 'C Programming' started by hpoliset, Oct 24, 2003.

  1. hpoliset

    hpoliset Guest

    I have a debugging question w.r.t core dumps with signal 4 Illegal
    instruction messages.

    I analyzed the core file through gdb. In simple english following is the
    pattern observed:

    I have an program with a piece of code -lets call it function1() that gets
    called by different callers. This function is executed 1000 's of times as
    while the binary is run and it works fine.

    However, under some strange circumstances (which is not reproducable
    consistently) if the call sequence happens to have a specific
    function_root() in the stack, the binary crashed in function1() with a
    signal 4 illegal argument exception. This never happens at the same place in
    the code.

    The crash stack looks as follows:
    function1() {
    ...some code
    ......
    .....
    returncode = function2(.......); -------------------------> crashes on this
    line
    ....
    }

    When I look at the code in function1 and beyond it looks all clean.

    These are the following questions i have:

    1) Is it posibble to identify from the core dump whether its a stack
    corruption. what are the other posibbilities.
    2) Is there any systematic process to be followed to identify the victim of
    the corruption followed by the actual culprit

    Please advice.
     
    hpoliset, Oct 24, 2003
    #1
    1. Advertising

  2. hpoliset

    jacob navia Guest

    "hpoliset" <> wrote in message
    news:V63mb.5958$...
    > I have a debugging question w.r.t core dumps with signal 4 Illegal
    > instruction messages.

    [snip]
    > However, under some strange circumstances (which is not reproducable
    > consistently) if the call sequence happens to have a specific
    > function_root() in the stack, the binary crashed in function1() with a
    > signal 4 illegal argument exception.


    Well, I do not get it. Illegal instruction or illegal argument???

    Illegal instruction means in most cases:
    1) The return address of the called function was corrupted (stack corruption),
    and when executing a return instruction the program jumps anywhere, in this
    case in a place that contained no instructions, probably into a data space, or
    somewhere.
    To trap this kind of problem, lcc-win32 offers you a g4 debug level, that injects instructions
    before executing a return to save the frame pointer in a global variable, that is later interpreted
    to output the name of the faulty function. Other compilers
    may use different schemas.

    2) A function pointer was used that wasn't initialized, or become invalid because the
    code it is pointing to was unloaded (dynamic library unloading too early).

    3) A function declared with _stdcall callig convention was called without prototype
    or with a wrong prototype. Under windows this is catched by the linker but other
    systems may be different.

    Look for temporary buffer variables like:
    char tmpbuf[28];

    Are there any strcpy memcpy or similar functions called with those variables?

    Look for any function pointer calls. Are those pointers valid?

    > This never happens at the same place in
    > the code.


    This would be consistent with a buffer overflow that only happens in special
    circumstances, not always.

    Good luck

    jacob
     
    jacob navia, Oct 24, 2003
    #2
    1. Advertising

  3. hpoliset

    Malcolm Guest

    "hpoliset" <> wrote in message
    >
    > However, under some strange circumstances (which is not
    > reproducable consistently) if the call sequence happens to have a
    > specific function_root() in the stack, the binary crashed in function1()
    > with a signal 4 illegal argument exception. This never happens at the
    > same place in the code.
    >

    If the crash doesn't show up consistently, this makes it very hard to debug.
    Try to create a situation where the bug is reproducible, maybe by commenting
    out sections of code, or feeding the program the same data set.
    >
    > 1) Is it posibble to identify from the core dump whether its a stack
    > corruption. what are the other posibbilities.
    >

    If the error code is "illegal argument" that would imply that the arguments
    to the function have been corrupted. Arguments are not necessarily passed on
    the stack. It could be that the caller is loading bad data into a register.
    >
    > 2) Is there any systematic process to be followed to identify the victim >

    of the corruption followed by the actual culprit
    >

    Unfortunately you are unlikely to have a "stack integrity check" function
    supplied. A debugger will tell you where the program crashed, so you know
    that the arguments to that function are corrupt. This probably means that
    the error is in the caller (you could try writing a stub version of the
    function that crashed, that adds one to each of its arguments, and see if
    the program still crashes in the same place. This would rule out the callee
    as a source of the crash.)
    However the calling function could be fine, but be itself called with
    invalid data. There is no magic bullet. You just have to trace back the
    program flow until you come to the problem.
     
    Malcolm, Oct 26, 2003
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John Carron

    Debugging Newbie Question

    John Carron, Jun 14, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    675
    John Carron
    Jun 15, 2005
  2. Ashish

    newbiew ( debugging question )

    Ashish, Oct 29, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    325
    Kevin Spencer
    Oct 30, 2003
  3. Johann Blake
    Replies:
    1
    Views:
    1,246
    Hermit Dave
    Jan 5, 2004
  4. jacob navia

    Debugging C vs debugging C++

    jacob navia, Oct 26, 2006, in forum: C Programming
    Replies:
    11
    Views:
    627
    Ian Collins
    Oct 27, 2006
  5. AAaron123
    Replies:
    3
    Views:
    691
    AAaron123
    Jul 28, 2009
Loading...

Share This Page