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 10 1557
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).
--
Greetings
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!!! : )
"Jochen Kalmbach [MVP]" <no********************@holzma.de> wrote in message
news:O9**************@TK2MSFTNGP12.phx.gbl... 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).
-- Greetings Jochen
My blog about Win32 and .NET http://blog.kalmbachnet.de/
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
>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
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq
> 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.
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
"Peter Oliphant" <po*******@RoundTripInc.com> wrote in message
news:ux*************@TK2MSFTNGP15.phx.gbl... 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!!! : )
"Jochen Kalmbach [MVP]" <no********************@holzma.de> wrote in message news:O9**************@TK2MSFTNGP12.phx.gbl... 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).
-- Greetings Jochen
My blog about Win32 and .NET http://blog.kalmbachnet.de/
On Mon, 10 Oct 2005 17:25:29 -0700, "Peter Oliphant"
<po*******@RoundTripInc.com> wrote: 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/de...timechecks.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 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.
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...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>
--
Doug 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... : )
"Doug Harrison [MVP]" <ds*@mvps.org> wrote in message
news:g4********************************@4ax.com... On Mon, 10 Oct 2005 17:25:29 -0700, "Peter Oliphant" <po*******@RoundTripInc.com> wrote:
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/de...timechecks.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 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.
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...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>
-- Doug Harrison VC++ MVP
On Tue, 11 Oct 2005 10:04:24 -0700, "Peter Oliphant"
<po*******@RoundTripInc.com> wrote: 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.
--
Doug Harrison
Visual C++ MVP This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: babak |
last post by:
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...
|
by: Rohit Raghuwanshi |
last post by:
Hello all,
we are running a delphi application with DB2 V8.01 which is causing
deadlocks when rows are being inserted into a table. Attaching the
Event Monitor Log (DEADLOCKS WITH DETAILS) here....
|
by: CJ Silin |
last post by:
Hello, I have a solution which is comprised of 4 projects. One of the
project is "used" by the other 3. In each of those 3 project, I created
a reference to the project it was going to be using...
|
by: Hari |
last post by:
Guys please help me to solve this strange problem what Iam
getting as follows..
Trying to instantiate a global instance of a template
class as follows :-
when i build this code with debug and...
|
by: David++ |
last post by:
Hi there,
I have built a DLL in Visual C++ 6. When I build the DLL it builds fine for
the debug version of the DLL (and this DLL works fine), however, I seem
unable to build a Release version of...
|
by: vedrandekovic |
last post by:
Hi,
I have already install Microsoft visual studio .NET 2003 and MinGw,
when I try to build a extension:
python my_extension_setup.py build ( or install ) , I get an error:
LINK : fatal...
|
by: fniles |
last post by:
I am using VisualStudio 2005 (VB.Net).
A weird thing happens. I used to have a button and a textbox on my form, and
I deleted them. I do a Build on a Release mode. But, the EXE that it creates
is...
|
by: Russ |
last post by:
I have a Web Service that was originally created with .NET VC 2003,
and subsequently converted to the 2005 version. It works fine when
built as a debug version, and run on the workstation it was...
|
by: MaheBytes |
last post by:
I have been facing a problem with UDP socket programming. I have to reuse port number for two different IP address. I am actually using SO_REUSEADD. I have no problem with debug version but with...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
| |