 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Languages / Managed C++ / October 2005Problem only in release version!
Hi everybody I'm working with a project in embedded Visual Studio 4 and I have a general problem which I hope that somebody can help me with. My problem is the following: My project works fine in debug version but behaves strangely and sometimes crashes when I run it in release version. I suspect that it is some sort of memory problem but it is not that easy to find out what the problem exactly is (the project is rather big with maybe 30000 lines of code). It should be the same code that runs in the both versions, right? Or is there some part of the code in a project that might differ in debug and release version? Thanks for all your help. Regards. /Babak Hi babak! > My project works fine in debug version but behaves strangely and > sometimes crashes when I run it in release version. See: Surviving the Release Version http://www.flounder.com/debug_release.htm Mostly it has to do with uninitialized data (in debug this data will get soe "default" value; but in release it will get some random numbers).  SignatureGreetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/ Just to affirm Jochen's point, the Debug version initializes most variables to zero. The Release version will not initialize anything 'naturally' (meaning without you writing code to do so), and hence many of the variable are often given a 'random' value upon loading ('random' in that they keep the contents of the memory addresses they happen to get assigned to). Thus, your new errors are likely the result of some variable that works fine if initialized to zero, but don't work if not initialized to zero (or not in some range, non-negative, etc.). Since an application doesn't always get loaded at the same place and memory, and because even the same place in memory can have different values depending on when you load your program (that's why it's RAM not ROM...hehe), you can get random bugs and un-stable executions of the Release version (i.e., it might do different things on different runs depending on the 'random' nature of your variables) even if it is totally stable in Debug mode. Hope that helps!!! : ) > Hi babak! > [quoted text clipped - 6 lines] > Mostly it has to do with uninitialized data (in debug this data will get > soe "default" value; but in release it will get some random numbers). Jochen and Peter, Thanks for your replies. Now the problem for me is to find out where in my code variables could be uninitialized... (as I said before, it is a huge project I'm running). Regards. /Babak Hi babak! > Thanks for your replies. Now the problem for me is to find out where in > my code variables could be uninitialized... (as I said before, it is a > huge project I'm running). AFAIK VC7.1/8 informs you about uninitialized variables. See: C4700 http://msdn.microsoft.com/library/en-us/vccore/html/c4700.asp SignatureGreetings Jochen My blog about Win32 and .NET http://blog.kalmbachnet.de/ > Thanks for your replies. Now the problem for me is to find out where in > my code variables could be uninitialized... (as I said before, it is a > huge project I'm running). 30000 lines is not really a big project ;-) But maybe for embedded it is. The problem is that it could be anything causing it. So some questions: * Did you create the code yourself? * Did it ever work? * When did you notice when it didn't work anymore? * What did yo chance before you discovered this problem? * Do you initialize every variable yourself? * Are you using multi-threading? The difference between release and debugging could be that your code is mapped differently. For example: You might have and unitialized pointer that by luck points to a memory that does not generate an access violation in the debug version but does in the release. Another thing might be timing, release is faster and you might end up into a racing condition. Or if you use multi threading that somehow you gets into a deadlock. One thing you could try is to run the debugging version on a different computer. See if the problem occurs, it might be there, but so far you did not notice it. I hope this helps to point you in th right direction. >the Debug version initializes most variables to zero. In another bid to dispel this myth - a debug build doesn't do this. In newer versions of VC++, the compiler has run-time diagnostic options that will initialise automatic (stack) variables to a special value in order to detect use of an uninitialised variable. If this option isn't used, automatic variables are pseudo-random values that might have a higher probability of being zero in a debug build. There's no magic that initialises automatic variables to zero in debug builds. Dave SignatureMVP VC++ FAQ: http://www.mvps.org/vcfaq If it is crashing I'd check overflowing of variable space on the stack (local variables). For example, if you set up a char buffer to hold 10 chars and you add 11 to it. This kind of thing is very easy to do. The Debug version may still have the problem, but the stack space is better protected and the memory is not arranged the same so at run time even if the problem is really still there it may not crash your program. As others have suggested uninitialized pointers, etc. are flagged at compile time so you'd see those warnings at least. However, going beyond allocated memory or a buffer on the stack is not always caught. Of course, if this is all managed code, that's not supposed to happen, but VC allows native and mixed which opens it up again. Tom > Just to affirm Jochen's point, the Debug version initializes most > variables [quoted text clipped - 29 lines] >> Mostly it has to do with uninitialized data (in debug this data will get >> soe "default" value; but in release it will get some random numbers). >Just to affirm Jochen's point, the Debug version initializes most variables >to zero. The Release version will not initialize anything 'naturally' >(meaning without you writing code to do so), and hence many of the variable >are often given a 'random' value upon loading ('random' in that they keep >the contents of the memory addresses they happen to get assigned to). The debug version doesn't initialize anything to zero that isn't zero-initialized in the release version. The /RTCs documentation explains why you're more likely to observe zero as the value of uninitialized stack-based variables in debug builds that don't use /RTCs. /RTC (Run-Time Error Checks) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vcr efrtcruntimechecks.asp In addition, the debug heap manager sets memory to certain non-zero values to help diagnose heap errors. >Thus, your new errors are likely the result of some variable that works fine >if initialized to zero, but don't work if not initialized to zero (or not in [quoted text clipped - 5 lines] >different runs depending on the 'random' nature of your variables) even if >it is totally stable in Debug mode. The OS (NT-based Windows anyway) only ever hands out memory pages initialized to zero. In fact, there's an OS thread whose purpose in life is to populate a zeroed page list: Inside Memory Management, Part 2 http://www.windowsitpro.com/Articles/Print.cfm?ArticleID=3774 <q> Pages on the standby page list move to the zeroed page list after a special thread, called the zero-page thread, clears their content. The zero-page thread executes in the background at priority 0. It runs only if no other thread can run, and its job is to move pages from the free page list to the zeroed page list as it clears their content. ... The necessity of zeroing a page before assigning it to the working set of a different process is a C2 security requirement. </q> SignatureDoug Harrison VC++ MVP So I was right for the wrong reason then.... : ) By the way, another less likely 'source' of the problem is if any of the application has required code in an 'assert'. Any code in an 'assert' is is not executed in Release mode (I believe, but I also thought Debug initialized variables to zero, so what do I know...hehe) . Most people don't put anything but comparison checks in asserts, and not functioning code, but you never know... : ) >>Just to affirm Jochen's point, the Debug version initializes most >>variables [quoted text clipped - 48 lines] > different process is a C2 security requirement. > </q> >So I was right for the wrong reason then.... : ) > >By the way, another less likely 'source' of the problem is if any of the >application has required code in an 'assert'. Any code in an 'assert' is is >not executed in Release mode (I believe, but I also thought Debug >initialized variables to zero, so what do I know...hehe) . It's true; asserts go away entirely in Release mode. (More generally, the standard assert macro expands to nothing if NDEBUG is #defined, while MFC's ASSERT goes away if _DEBUG isn't #defined.) >Most people don't put anything but comparison checks in asserts, and not >functioning code, but you never know... : ) It definitely happens. Besides code that does something overtly, you should also avoid asserting on code that can have more or less subtle side effects, such as throwing exceptions. Ideally, your asserts or _DEBUG code cannot change any application state. SignatureDoug Harrison Visual C++ MVP Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.