Thread: Strange Bus Error

  1. #1
    Registered User
    Join Date
    Feb 2005
    Posts
    4

    Strange Bus Error

    So I'm working on a ray tracer and I'm getting a really strange bus error that shows up like this in gdb:

    Code:
    (gdb) info stack
    #0  0xfee424ec in realfree () from /usr/lib/libc.so.1
    #1  0xfee42cb8 in cleanfree () from /usr/lib/libc.so.1
    #2  0xfee41dec in _malloc_unlocked () from /usr/lib/libc.so.1
    This seems to occur somewhere near the end of the program, but well past any portion I have written. In fact, there are no local variables or context available in any of these frames. I'm working on going back and checking to make sure I'm deleting all my allocated memory, but does anyone have any specific advice about debugging this more precisely?

    BTW, I'm compiling using g++ 3.3 on Solaris.

  2. #2
    Registered User Sake's Avatar
    Join Date
    Jan 2005
    Posts
    89
    It looks like some memory you allocated got corrupted somehow. Not like that helps you debug it, but memory errors are among the hardest to find and fix.
    Kampai!

  3. #3
    Registered User
    Join Date
    Feb 2005
    Posts
    4
    Thanks for the response. Any idea why these functions are running after my code is apparently finished? If I had some sense of what they were trying to do, and what they might be referencing it would shed some light on the situation.

  4. #4
    Registered User Sake's Avatar
    Join Date
    Jan 2005
    Posts
    89
    >Any idea why these functions are running after my code is apparently finished?
    There's a lot of hidden framework around your program. Consider destructors as a general example. They run behind the scenes after your code is apparently finished.
    Kampai!

  5. #5
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,656
    > but does anyone have any specific advice about debugging this more precisely?
    Use valgrind or electric fence.
    These trap out of bound memory accesses at the point of access.

    Segmentation faults usually show up when you try and use the corrupted memory for it's original purpose (which is usually much later), and is seldom anywhere near where the actual corruption took place.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  6. #6
    Registered User
    Join Date
    Feb 2005
    Posts
    4
    gdb has always done the trick for me. I've done a fair amount of network and system level C coding, so segfaults are nothing new. Where I think I'm getting stuck is the C++ memory management framework. My code seems to work, but then crashes when it's cleaning things up (default destructors?) The annoying part is that I'm extending pre-existing code, so it's entirely possible that they did something wrong which only manifests itself with my code. For instance, I'm pretty sure they have memory leaks because I see many new()s without corresponding delete()s.

    Anyway, I'll check into those programs to see if they shed any more light on what's going on. Thanks a lot people.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Testing some code, lots of errors...
    By Sparrowhawk in forum C Programming
    Replies: 48
    Last Post: 12-15-2008, 04:09 AM
  2. load gif into program
    By willc0de4food in forum Windows Programming
    Replies: 14
    Last Post: 01-11-2006, 10:43 AM
  3. Post...
    By maxorator in forum C++ Programming
    Replies: 12
    Last Post: 10-11-2005, 08:39 AM
  4. Dikumud
    By maxorator in forum C++ Programming
    Replies: 1
    Last Post: 10-01-2005, 06:39 AM
  5. Learning OpenGL
    By HQSneaker in forum C++ Programming
    Replies: 7
    Last Post: 08-06-2004, 08:57 AM