Find the answer to your Linux question:
Results 1 to 2 of 2
I've been debugging an application at work lately using KDbg and seem to have found a problem that I can't really get through and which really hinders my work. The ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Nov 2008
    Posts
    28

    Unknown callstack in KDbg


    I've been debugging an application at work lately using KDbg and seem to have found a problem that I can't really get through and which really hinders my work. The program I debug seems to be crashing every few hours, but there is one problem that makes it very hard (if not next to impossible) to track.

    Every time that my program crashes, KDbg will halt just before shutting the program down, telling me a segmentation fault occurred. However, the callstack for the thread that is causing the problem only holds three lines, which are only filled with question marks. As a result I do not have access to a list of variables and their values or any other guide that can tell me anything that could point to a problem. Does anyone here have any idea why the callstack would seem to be unavailable in KDbg and what I could do to work around this?

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,737
    This sort of behavior with regard to debugging segfaulted applications is not uncommon when memory problems mung the stack. Because the stack is corrupted, the debugger cannot tell you where it is, or what function was being called when the core dump occurred. This is a good situation to compile the source fully debuggable and with memory checking enabled. Then run it in the debugger directly. It should tell you when you access and write to invalid memory, such as overflowing a buffer.

    Alternatively, you can use a commercial memory checker tool like IBM/Rational's Purify.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •