Printable View
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?
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.
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.
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).
Strange, but a dream come true.Quote:
Originally Posted by Bubba
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.
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.Quote:
Knowingly releasing a program which crashes is intolerable.
But in this particular case I would imagine this type of crash happens every time since it is certainly a memory error.
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
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.
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.Quote:
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
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.
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.Quote:
Originally Posted by jeffcobb
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.Quote:
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.
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.Quote:
Since most variables are, or should have been, initialized to zero, this can hide the uninitialized memory bug.
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.
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....Quote:
Originally Posted by brewbuck
<rant mode off...I now return you to your bug...>
Peace
Jeff
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.Quote:
Originally Posted by brewbuck
This is correct of course, but the reason things end up "mostly" zero is simply because most memory is zero. The OS itself clears memory pages to zero when they are committed into a process's address space. It's not the program that does it, it's the OS itself.Quote:
Originally Posted by Bubba
(If the OS didn't do that, then a program could get data from other extinct processes by just malloc'ing a big block of memory and looking at it -- that's obviously an unacceptable security problem)
There was a time when 0xCDCD was the default although IIRC isn't there a setting somewhere in VS where you can set what the default value is? Been so long I cannot remember...Quote:
Originally Posted by IceDane
I think you can probably configure it. In any case, you can always override the global new operator to fill dynamic memory with anything you want, really.Quote:
Originally Posted by jeffcobb
In our software testing, we enable floating-point exceptions so that FP divides by zero or other bad things will cause a crash that we can track. Once, we had a very rare crash due to an invalid IEEE bit pattern that was very hard to track down. We knew it was uninitialized memory, but it was difficult to figure out where, because most of the time, although the value was uninitialized, it represented some valid number and everything worked okay. A developer around here had the bright idea to fill all dynamic memory with the value 0x7fc00001, which represents an invalid 32-bit IEEE float value. We INSTANTLY found the problem.
For MSVC and Win32 (I think) all stack mem is init to 0xCCCCCCCC and dynamic is 0xCDCDCDCD. Free'd dynamic memory is 0xFEEEFEEE so if you see that one of your pointers has this address you know someone else pulled the rug out from under you.
There are several other codes used like 0xDEADBEEF and so forth.