Crash in Debugger

This is a discussion on Crash in Debugger within the C++ Programming forums, part of the General Programming Boards category; I have a program here that compiles and runs fine and outputs pretty much as i expect, apart from a ...

  1. #1
    Registered User rogster001's Avatar
    Join Date
    Aug 2006
    Location
    Liverpool UK
    Posts
    1,438

    Crash in Debugger

    I have a program here that compiles and runs fine and outputs pretty much as i expect, apart from a couple of adjustments to stop some repeat output, anyway i was looking into sorting this out and have found that when i step through in the debugger i get a seg fault crash? why would that happen if it runs ok in normal mode?? or is that the point?

  2. #2
    Registered User
    Join Date
    Oct 2006
    Location
    Canada
    Posts
    1,243
    A number of "special" things happen in the two versions of the code ("debug" and "release", in Microsoft terms). Can you post the code, if it is short enough to reproduce the problem (in any build configuration)? Alternatively, you can just search the documentation for the compiler your using, to see what "special" things it is doing in the problem build mode.

  3. #3
    Registered User
    Join Date
    Dec 2006
    Location
    Canada
    Posts
    3,183
    It's possible the compiler is only doing optimizations in "normal mode", and that changes your code by moving things around. If your code, for example, has a buffer over-run bug, it may only crash in one mode but not the other, because only in that mode is the memory immediately following the array inaccessible (by coincidence).

    A crash means there is a bug. No crash does NOT mean there is no bug.

    It's quite common actually, I have seen it a few times already.

    It just means there is a bug in your code, or the compiler. Most likely your code.

    If it crashes in the debugger, isn't that all you need? Just examine the state and fix the bug.

  4. #4
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Usually it crashes in release as opposed to debug so that is a bit strange. MSVC doesn't babysit nearly as much as Borland used to (zeroing out memory and variables for you which could hide tons of bugs). Seg fault is most likely due to accessing memory you don't own or have not allocated. Sounds like a pointer overrun (essentially a buffer or array overrun).

  5. #5
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,249
    Quote Originally Posted by Bubba View Post
    Usually it crashes in release as opposed to debug so that is a bit strange.
    Strange, but a dream come true.

    The important thing to realize is that if the program crashes in ANY build mode, there is a problem. Whether it crashes in debug or release just changes how hard it is to find the bug. Never ignore a crash no matter what build type. Software crashes should be treated as unacceptable failures and diagnosed. Knowingly releasing a program which crashes is intolerable.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  6. #6
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Knowingly releasing a program which crashes is intolerable.
    Agreed, yet it is done every day in every business around the world. We see it in video games, applications, and the like. A crash is all about the frequency at which it occurs IE: the probability it will affect a great many of your customers, and whether or not there are workarounds, etc. Personally as a developer I would never release with a known crash. So far I have not had to deal with this issue since quality is a major concern at my current company.

    But in this particular case I would imagine this type of crash happens every time since it is certainly a memory error.
    Last edited by VirtualAce; 12-26-2009 at 11:42 AM.

  7. #7
    Registered User rogster001's Avatar
    Join Date
    Aug 2006
    Location
    Liverpool UK
    Posts
    1,438

    Bughunt

    Yea, no way was leaving known bug in there, was just enquiring bc never seen this happen before, have traced it and of course is array based but is still confusing because the array appears to b filled correctly and itsnt bounds issue cos bug is mid array

  8. #8
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Your spelling and use of grammar is atrocious. I understand if your first language is not English (but based on your location this is not an excuse) but if you cannot form a suitable sentence and/or paragraph with correct spelling it really reflects poorly on you. Not to mention it makes the old timers here pretty much ignore your posts.

    Slow it down and express your thoughts concisely and clearly. There isn't a fire here we are rushing to put out.

    You are obviously accessing memory that has not been allocated. In debug and release the compiler and OS will let you get away with this up to a point. Over-running an array by one element won't crash per se but over-running by several elements will. It also depends on the data type of the array as to how quickly it will crash. Check for array-overruns or post the offending section of code so we can help. If this is for a work project then attempt to re-factor the problem into your own code and post it. We will need to see where the array is allocated, accessed, and cleaned up.

  9. #9
    Registered User rogster001's Avatar
    Join Date
    Aug 2006
    Location
    Liverpool UK
    Posts
    1,438
    Your spelling and use of grammar is atrocious. I understand if your first language is not English (but based on your location this is not an excuse) but if you cannot form a suitable sentence and/or paragraph with correct spelling it really reflects poorly on you. Not to mention it makes the old timers here pretty much ignore your posts
    Wow, many apologies, my first language most definitely is English thank you very much, the message should be 'don't bother using your phone to reply to posts, there is limited text space available and its better to just wait', but you could not have known that so point taken.

    As far as the problem goes i am about to have another look, as i tried to say the elements with the problem are about one third of the way in to the array with the fault, the debugger reveals about 3 that do not get written to correctly, although the output when running normally does not reflect this. If i cant sort out i will try and put a postable code section together, cheers.

  10. #10
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Query: is this app multithreaded? Reason I ask is that in such a situation a crash can happen under a certain sequence of context switches and not (or worse, seemingly not as in the case of undetected memory corruption) in a different sequence. Two things to keep in mind here is that in some compilers (used to be all) in "debug" mode, all variables are initialized to a value of some kind whereas in release mode, only those that you specifically (programmatically) initialize are. Just by itself this behavior will result in release and debug mode running/acting differently. Then if you add in the fact that a debugger will enforce a specific or artificial sequence of context switches, you have a recipe for fun...
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  11. #11
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,249
    Quote Originally Posted by jeffcobb View Post
    Query: is this app multithreaded? Reason I ask is that in such a situation a crash can happen under a certain sequence of context switches and not (or worse, seemingly not as in the case of undetected memory corruption) in a different sequence. Two things to keep in mind here is that in some compilers (used to be all) in "debug" mode, all variables are initialized to a value of some kind whereas in release mode, only those that you specifically (programmatically) initialize are. Just by itself this behavior will result in release and debug mode running/acting differently. Then if you add in the fact that a debugger will enforce a specific or artificial sequence of context switches, you have a recipe for fun...
    Yes -- In debug mode, uninitialized memory is usually filled with a bit pattern that helps to shake out these kinds of bugs -- on Windows, debug uninit memory is filled with 0xCD repeated over and over. In release, the memory will probably just contain zeros. Since most variables are, or should have been, initialized to zero, this can hide the uninitialized memory bug.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  12. #12
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    Wow, many apologies, my first language most definitely is English thank you very much, the message should be 'don't bother using your phone to reply to posts, there is limited text space available and its better to just wait', but you could not have known that so point taken.
    Hehe. With all the ways to get online nowadays I guess I should consider that some might be posting from a phone and thus the reason for their garbled messages. My apologies.

    Since most variables are, or should have been, initialized to zero, this can hide the uninitialized memory bug.
    According to my experience the only variables intialized to zero in release are those specifically assigned a value of zero by the programmer. In other words I don't think that the assembly that MSVC spits out in any way auto-inits anything to zero. I remember back in the day that Borland and possibly DJGPP did do this which made debugging uninitialized variable/memory errors extremely difficult. Again I'm not sure if Borland and DJGPP only did this in release or in debug since I didn't even understand the concept of release and debug back then.
    Last edited by VirtualAce; 12-28-2009 at 07:43 PM.

  13. #13
    Registered User rogster001's Avatar
    Join Date
    Aug 2006
    Location
    Liverpool UK
    Posts
    1,438
    thanks for the advice all, i fixed it by looking at the actual initialisation routine which i was previously stupidly ignoring as working perfectly and could not possible be at fault...hehe, famous last words....
    there was a simple algorithm converting the data read in from a file, it was going wrong in some 'special' cases and this meant that a key condition was not being met at all, so nothing got read into my array there.
    By the way my release version was wrong also, the output of program is a bit intricate and it was hard to see anything wrong, hence me thinking the release worked fine, but i found that where the bug had occured nothing at all was output, which had effectively disguised it.

  14. #14
    Registered User jeffcobb's Avatar
    Join Date
    Dec 2009
    Location
    Henderson, NV
    Posts
    875
    Quote Originally Posted by brewbuck View Post
    Yes -- In debug mode, uninitialized memory is usually filled with a bit pattern that helps to shake out these kinds of bugs -- on Windows, debug uninit memory is filled with 0xCD repeated over and over. In release, the memory will probably just contain zeros. Since most variables are, or should have been, initialized to zero, this can hide the uninitialized memory bug.
    l am trying to remember which system/OS filled memory with 0xDEADBEEF ... in any event I remember a single uninitialized var on Win31 causing us grief b/c if randomly initialized itself to zero on some machines (and this was a proper value as per the application) and some random non-zero number on others causing mayhem. Of course, the machines that it initialized to zero on were all dev boxen and the machine it went nuts on were the clients, 50 miles away...in the dead of winter....brrr! That lesson alone as re-inforced the "init your vars" rule in my mind ever since....even if the vars are not yours (worked on a team) there was never a case where it was "right" not to init....

    <rant mode off...I now return you to your bug...>

    Peace
    Jeff
    C/C++ Environment: GNU CC/Emacs
    Make system: CMake
    Debuggers: Valgrind/GDB

  15. #15
    Ex scientia vera
    Join Date
    Sep 2007
    Posts
    478
    Quote Originally Posted by brewbuck View Post
    Yes -- In debug mode, uninitialized memory is usually filled with a bit pattern that helps to shake out these kinds of bugs -- on Windows, debug uninit memory is filled with 0xCD repeated over and over. In release, the memory will probably just contain zeros. Since most variables are, or should have been, initialized to zero, this can hide the uninitialized memory bug.
    As far as I can see, and have seen, when writing apps for windows using Visual Studio with debug config, all vars are filled with 0xCC, not 0xcd, but obviously, that is an irrelevant detail.
    "What's up, Doc?"
    "'Up' is a relative concept. It has no intrinsic value."

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. executing from debugger
    By hedwin in forum C++ Programming
    Replies: 8
    Last Post: 10-11-2007, 04:05 PM
  2. Replies: 3
    Last Post: 07-24-2007, 04:25 PM
  3. Can not debug a crash
    By hannibar in forum Windows Programming
    Replies: 2
    Last Post: 06-30-2007, 10:02 AM
  4. FYI: asctime(gmtime(&mytime)) = crash!
    By anonytmouse in forum C Programming
    Replies: 2
    Last Post: 09-29-2003, 02:24 AM
  5. MSVC++ Debugger (it kills me)
    By lightatdawn in forum A Brief History of Cprogramming.com
    Replies: 6
    Last Post: 06-29-2002, 07:37 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21