Released app version of msvc 1.52 gives GPF.
Yoong Hor Meng -- eng30391@leonis.nus.sg
Monday, December 02, 1996
Environment: VC++ 1.52 Windows 3.1
The application I am writing gives GPF in released mode but not in debug
mode. I saw some body asked the same question some times ago. The
problem is someting about MCVC 1.52 does not initialize "some" variables.
I have check microsoft knowledge base but I can't find any help.
Is their a solution to it? Or what type of varaibles that I need to
initialize?
Grant Shirreffs Great Elk -- Grant.S@greatelk.com
Wednesday, December 04, 1996
I'm not sure which initialisation problems you are referring to
specifically, but I have found a few times that the MSVC 1.5 generates
strange code in release mode when you try to initialise part of a
structure. For example:
OPENFILENAME ofn={sizeof(ofn)};
causes problems in release.
To find any more than that, you'd need to give more information.
>----------
>From: Yoong Hor Meng
>Sent: Monday, 02 December 1996 7:04 PM
>To: mfc-l@netcom.com
>Subject: Released app version of msvc 1.52 gives GPF.
>
>Environment: VC++ 1.52 Windows 3.1
>
>The application I am writing gives GPF in released mode but not in
>debug
>mode. I saw some body asked the same question some times ago. The
>problem is someting about MCVC 1.52 does not initialize "some"
>variables.
>I have check microsoft knowledge base but I can't find any help.
>Is their a solution to it? Or what type of varaibles that I need to
>initialize?
>
>
P. Senthil -- senthilp@geocities.com
Wednesday, December 04, 1996
You've hit upon one the most terrifying problems in VC++.
To provide memory diagnostics during debug mode, MFC defines certain
extra things which are absent in the release mode. So generally there is
a GPF in release mode.
The new operator allocates 512 odd bytes more in Debug mode than in
Release mode. So if you take care of your allocations, then there should
be no problem.
Yoong Hor Meng wrote:
>
> Postage paid by:
> [Image]
> Catalog of the Internet
>
> ---------------------------------------------------------------
>
> Environment: VC++ 1.52 Windows 3.1
>
> The application I am writing gives GPF in released mode but not in debug
> mode. I saw some body asked the same question some times ago. The
> problem is someting about MCVC 1.52 does not initialize "some" variables.
> I have check microsoft knowledge base but I can't find any help.
> Is their a solution to it? Or what type of varaibles that I need to
> initialize?
--
P. Senthil
-----------------------------------------------------------------------
1, 7th Avenue (West),
7th Main Road,
Dhandeeswaram Nagar,
Velachery,
MADRAS - 600 042.
Mail: senthilp@geocities.com
Homepage: www.geocities.com/SiliconValley/Heights/6504
David Lowndes -- David.Lowndes@bj.co.uk
Wednesday, December 04, 1996
>The application I am writing gives GPF in released mode but not in debug
mode. I saw some body asked the same question some times ago. The
problem is someting about MCVC 1.52 does not initialize "some"
variables.
I have check microsoft knowledge base but I can't find any help.
Is their a solution to it? Or what type of varaibles that I need to
initialize?
<
You can debug your release version to find the problems if you change
the options to include the debug information (Compiler - Debug Options,
& Linker - Output - Generate Debugging Information).
Dave
Jesper de Jong -- jesperdj@ati.cmg.nl
Wednesday, December 04, 1996
[Mini-digest: 12 responses]
Environment: VC++ 1.52 Windows 3.1
> The application I am writing gives GPF in released mode but not in debug
> mode. I saw some body asked the same question some times ago. The
> problem is someting about MCVC 1.52 does not initialize "some" variables.
> I have check microsoft knowledge base but I can't find any help.
> Is their a solution to it? Or what type of varaibles that I need to
> initialize?
Check if you've put statements in an ASSERT() statement which should have
been in a VERIFY() statement. This is the most common cause for
differences between debug and release versions.
The difference between ASSERT() and VERIFY(): The ASSERT() evaluates to
nothing in release mode (it disappears completely), while the expression
in a VERIFY() statement is still executed in release mode. See the MFC
docs.
Regards, Jesper
-------------------------------------------
Jesper de Jong jesper.de.jong@cmg.nl
-------------------------------------------
-----From: Patrice Buriez
Hi Yoong,
>> The application I am writing gives GPF in released mode but not in debug
>> mode. I saw some body asked the same question some times ago. The
>> problem is someting about MCVC 1.52 does not initialize "some" variables.
>> I have check microsoft knowledge base but I can't find any help.
>> Is their a solution to it? Or what type of varaibles that I need to
>> initialize?
I have recently experienced a similar problem, ie: no error when the
application is built in debug mode, and GPF when built in release mode.
This kind of problem can have many reasons: unitialized variables,
improper use of ASSERT rather than VERIFY, misplaced #ifdef _DEBUG, out
of synch dependencies, etc... Unfortunately, you do not provide enough
information to help us figure out your problem.
As a rule of thumb, I usually trust MFC and I first try to check my own
code.
Now, what can you do to solve your problem ?
First, make the linker generate a map file for your application:
"Options/Project" menu command,
"Linker" button,
"Common to Both" radio button,
"Output" item in the "Category" list box,
"Create MAP file" check box,
"OK" button,
"OK" button.
Second, rebuild a "clean" release application:
"Options/Project" menu command,
"Release" radio button,
"OK" button,
"Project/Scan All Dependencies" menu command,
"Project/Rebuild All" menu command.
I know it may take some time to rebuild the whole application. However,
I always do it when I experience a problem that I cannot understand by
checking my code. Compiler/linker time is far cheaper than debug time !
Third, run your application and check that it still fires the GPF.
If it does, do not angrily dismiss the dialog box: it may contain the
key to your problem. Write down the module name and the address at which
the GPF occurs.
If it doesn't, then your problem was probably an out of synch
dependencies problem. Don't forget to regularly "Scan All Dependencies":
it only takes a few time that can make you save a lot !
Fourth, if the GPF is still fired, exit Windows, reboot and restart
Windows. This will make you get rid of unfreed libraries. Before
restarting Windows, you may want to run CHKDSK or SCANDISK if your
application has stopped with unflushed files.
Fifth, run CodeView on your application (yes: on the release build),
from the "Tools/CodeView for Windows" menu command. Do not worry about
the "no debug information" warning. If your application requires command
line arguments, you can provide them using the "Run/Set Runtime
Arguments" menu command under CodeView. Then, run your application,
using the "Run/Go" menu command, and make it fire the GPF. Under
CodeView, your application will not be stopped with the
unfortunately-too-classical GPF dialog box. Rather, CodeView will show
you the assembly line where the error occured. This may be of few help
if you are not fond of x86 mnemonics, but there is more information than
this single faulty assembly line. Open the "Calls" menu under CodeView:
it will show you the list of currently nested function calls, with the
faulty assembly line address and its module name at the top of the menu.
Sixth, write down the contents of the "Calls" menu until you find the
module name of your application (same as the .EXE name). You'll may have
to select the "more" (or some name like that) menu command to see the
whole list of nested function calls.
What should you write down ? Each line in the "Calls" menu shows
something as "USER(1A) 2B3C:4D5E", where "USER" is the module name, "1A"
is the segment number, "2B3C" is the selector value and "4D5E" is the
offset value. Write down the module name, the segment number and the
offset value. The selector value is useless for us: it may change each
time you run your application, while the segment number is always the
same for a given function and is shown in the map file.
As some segment numbers in your application may be associated with
functions provided by MFC, you'll may want to write down the segment
number and the offset value for the whole consecutive block of lines
with the module name of your application.
Then you can exit from CodeView, using the "File/Exit" :-) menu command.
Seventh, open the map file (same name as you application with a .MAP
extension) under MSVC, and scroll down to the "Publics by Value" section
(at about the half of the file). Under the "Address" column, the map
file provides the segment number and the offset value of each function
in your application. The name of the function may be "decorated", due to
C++ name-mangling. Scroll down again to find the name of the functions
that were nested when the GPF occured. Note that the map file only
provides the offset value of the entry point of each function. Thus, you
must browse the "Address" column to find the function name with exactly
the same segment number as you wrote down under CodeView, and the
immediately-lower offset value than the one you wrote down under
CodeView.
Here is an example:
Imagine that the "Calls" menu under CodeView said "MYAPP(1A) 2B3C:4D5E",
and that the "Publics by Value" section of the map file looks like this:
001A:4D2C ?OnInitialUpdate@CMyView@@VECXXZ
001A:4E6E ?OnPreparePrinting@CMyView@@NECHPEUCPrintInfo@@@Z
Then, the name of the function that was nested when the GPF occured
would be CMyView::OnInitialUpdate().
All this will help you find the code portion which may have generated
the GPF.
Eighth, find the reason for the GPF.
Now that you know the sequence of function calls that lead to the GPF,
you can add AfxMessageBox() calls to display the state of your internal
variables and hopefully find any bug or bad assumption in your code.
Remember, TRACE does nothing in release mode.
Nineth, good luck !
By the way, it is not necessarily a bug in your code. However, trust MFC
until you can point out that there is a bug or an unexpected behaviour
in it, then try to find a work-around.
For you information, the problem that I have recently experienced was an
unexpected behaviour in the VerQueryValue() function in VER.DLL. As its
prototype shows, its takes an LPCSTR as its second parameter. Thus I had
coded something like that:
if (::VerQueryValue(lpvBlock, "\\VarFileInfo\\Translation", &lpBuffer,
&cb))
This worked fine in debug mode, but fired a GPF in release mode. Using
CodeView, I discovered that the second parameter is "globally" a "const
char FAR*" (by "globally", I mean that the string is not modified when
the function returns), but that this string is temporarily modified by
VerQueryValue(). This worked fine under debug mode, because the literal
string "\\VarFileInfo\\Translation" was stored by the compiler in a
read/write segment. It fired a GPF under release mode, because this
literal string was then stored by the compiler in a read-only code
segment. This is not a compiler bug... May be modifying the
VerQueryValue prototype with a LPSTR parameter would be sufficient to
solve the problem... In my case, I solved it like that:
CString sTranslation("\\VarFileInfo\\Translation");
if (::VerQueryValue(lpvBlock, sTranslation, &lpBuffer, &cb))
Here, the string buffer provided to VerQueryValue is allocated by
CString::CString() in a read/write segment.
Hope this helps !
Patrice
>----- =8^) ------------------------------------------------------
>Patrice BURIEZ
>Phone: +33 (1) 30 84 43 16
>Fax: +33 (1) 30 84 44 59
>Email: patriceb@businessline.tm.fr
>Visit: http://www.businessline.tm.fr
>-----------------------------------------------------------------
>Disclaimer:
>Opinions expressed are my own and are not those of my employer.
>-----------------------------------------------------------------
>
-----From: kenn@owl.co.uk (Ken Nicolson)
On Mon, 2 Dec 1996 14:04:26 +0800 (SST), you wrote:
>Environment: VC++ 1.52 Windows 3.1
>
>The application I am writing gives GPF in released mode but not in debug
>mode. I saw some body asked the same question some times ago. The
>problem is someting about MCVC 1.52 does not initialize "some" =
variables.
No, the problem is that the application code either does not initialise
some variables, or you write off the end of an array, or some other
undefined behaviour. It's just luck that the non-debug version works. For
example, code like this:
void foo()
{
char a[26];
char c =3D 'a';
int i;
for ( i =3D 0; i <=3D 26; i++ )
a[ i ] =3D c++;
...
}
may appear to work in debug mode as a "safe" memory location may be
overwritten, but in the release build when you try to write to the 27th
element of a[], you could corrupt the return address on the stack.
Other undefined behaviour could also appear to work in debug mode, but =
fail
in release mode due to the compiler producing different instruction
sequencing, such as "a[i] =3D i++" or "(getc(fp) << 8) | getc(fp)".
Another fault could be a genuine compiler bug - in the 16-bit versions,
I've seen a number of bugs in floating point optimisations (we resorted =
to
turning off speed optimisations for the number-crunching routines), and I
once had a very nasty code generation error in some quite simple integer
if-then logic.
>I have check microsoft knowledge base but I can't find any help.
>Is their a solution to it? Or what type of varaibles that I need to
>initialize?
Turn warning level up to 4, and carefully check all output - you may have
to turn off warnings for the MS headers, but it will tell you about
variables used before assigned.
To find memory overwrite errors, you will need to invest in NuMega's
BoundsChecker or similar - it may appear expensive, but it will repay
itself many times over!
=46or undefined behaviour, you need to get hold of Lint - such as PCLint =
from
Gimpel - which will check for unsafe code such as examples listed.
However, just because something appears to work in debug mode, even with
all these tools used for diagnosis, there is no guarantee that release =
mode
will work too. Always do your QA test with the release code - that's what
the customer's getting, so that's what you should be testing.
HTH
Ken
-----From: "Sanu M Palil"
Those variables and pointers you assumed to be zero, but you didn't actually
make it so will be one point of interest. If you have bounce checker, it will
throw some light into your problem.
----------
> From: Yoong Hor Meng
> To: mfc-l@netcom.com
> Subject: Released app version of msvc 1.52 gives GPF.
> Date: Sunday, December 01, 1996 10:04 PM
>
> Environment: VC++ 1.52 Windows 3.1
>
> The application I am writing gives GPF in released mode but not in debug
> mode. I saw some body asked the same question some times ago. The
> problem is someting about MCVC 1.52 does not initialize "some" variables.
> I have check microsoft knowledge base but I can't find any help.
> Is their a solution to it? Or what type of varaibles that I need to
> initialize?
>
-----From: David Mayes
I have experienced similar problems and most of the time they stem from =
a char array that is too short, i.e.=20
char ctemp[15];
ctemp[15]='a'; // in debug, it may go un noticed but not in release.
This is especially true if the char array does not fit into an even byte =
boundary. You may be packing the code differently in debug than that =
for release.
----------
From: Yoong Hor Meng[SMTP:eng30391@leonis.nus.sg]
Sent: Monday, December 02, 1996 6:04 AM
To: mfc-l@netcom.com
Subject: Released app version of msvc 1.52 gives GPF.
Environment: VC++ 1.52 Windows 3.1
The application I am writing gives GPF in released mode but not in debug
mode. I saw some body asked the same question some times ago. The
problem is someting about MCVC 1.52 does not initialize "some" =
variables.
I have check microsoft knowledge base but I can't find any help.
Is their a solution to it? Or what type of varaibles that I need to
initialize?
-----From: Elliott Kleinrock
At 02:04 PM 12/2/96 +0800, you wrote:
>Environment: VC++ 1.52 Windows 3.1
>
>The application I am writing gives GPF in released mode but not in debug
>mode. I saw some body asked the same question some times ago. The
>problem is someting about MCVC 1.52 does not initialize "some" variables.
>I have check microsoft knowledge base but I can't find any help.
>Is their a solution to it?
Yes, ...
>Or what type of varaibles that I need to initialize?
Initialize all varaibles.
- Elliott (elliott@flexi.com)
Flexi International (203) 925-3096 X3018
-----From: Mike Blaszczak
At 08:26 12/4/96 +1300, you wrote:
>Environment: VC++ 1.52 Windows 3.1
>
>The application I am writing gives GPF in released mode but not in
>debug mode. I saw some body asked the same question some times
>ago. The problem is someting about MCVC 1.52 does not initialize "some"
>variables.
This is a myth. If you don't initialize a variable, it isn't initialized.
The compiler doesn't emit extra code in "debug builds" to initialize
uninitialized variables.
Static variables, by the definition of the language, are initialized to zero
unless explicitly initialized to something else.
If you link to the debug libraries provided with some builds of the compiler,
or if you run your application under a debugger in certain operating systems,
you'll find that memory newly allocated from the operating system heap or
from the runtime library heap may be initialized by the operating system
or the runtime library. These situations are well-documented.
But individual variables are not initialized by any option (or any lack of
option) in any version of Microsoft's compilers. A variable is initialized
by the programmer.
.B ekiM
http://www.nwlink.com/~mikeblas/ <-- trip report central!
95 Honda VFR-750F / 88 Yamaha FZ-700 (damaged) / 94 Mazda RX-7
Serial #00050! / AMA - HRC - VFROC / Wang Dang Wankel
I am bored of this talk. It is time now for the dancing!
These words are my own - I do not speak on behalf of Microsoft.
-----From: Yoong Hor Meng
On Wed, 4 Dec 1996, Grant Shirreffs (Great Elk) wrote:
> I'm not sure which initialisation problems you are referring to
> specifically, but I have found a few times that the MSVC 1.5 generates
> strange code in release mode when you try to initialise part of a
> structure. For example:
>
> OPENFILENAME ofn={sizeof(ofn)};
>
> causes problems in release.
>
> To find any more than that, you'd need to give more information.
>
I have solved my problem using full debug information and mapping in the
release version. By checking the address returned by GPF dialog and the
one in the map, the problem was in InitApplication. Thank
-----From: joew@statsoft.com (Joe Willcoxson)
>Environment: VC++ 1.52 Windows 3.1
>
>The application I am writing gives GPF in released mode but not in debug
>mode. I saw some body asked the same question some times ago. The
>problem is someting about MCVC 1.52 does not initialize "some" variables.
>I have check microsoft knowledge base but I can't find any help.
>Is their a solution to it? Or what type of varaibles that I need to
>initialize?
My experience has been not to trust the optimizer that comes with VC++. I
would turn optimization off during your release build and see if that solves
the problem. In the past, I had applications that ran fine under a debug
build but had GPFs under release mode. I ran Bounds Checker and it could
not detect any problems and I was very careful with my memory allocations.
Someone else who had a similar problem clued me in to turn off optimization.
--
Gloria In Excelsius Deo
Joe Willcoxson (joew@statsoft.com), Senior Software Engineer
Visit us: http://www.statsoft.com, Visit me: http://users.aol.com/chinajoe
#define STD_DISCLAIMER "I speak only for myself"
-----From: "C.Zhang"
The difference is the stack. In debug mode, the stack is cleared to zero
automatically. So check those local variables allocated from the stack
specially structures without constructors.
Grant Shirreffs (Great Elk) wrote:
>
> I'm not sure which initialisation problems you are referring to
> specifically, but I have found a few times that the MSVC 1.5 generates
> strange code in release mode when you try to initialise part of a
> structure. For example:
>
> OPENFILENAME ofn={sizeof(ofn)};
>
> causes problems in release.
>
> To find any more than that, you'd need to give more information.
>
> >----------
> >From: Yoong Hor Meng
> >Sent: Monday, 02 December 1996 7:04 PM
> >To: mfc-l@netcom.com
> >Subject: Released app version of msvc 1.52 gives GPF.
> >
> >Environment: VC++ 1.52 Windows 3.1
> >
> >The application I am writing gives GPF in released mode but not in
> >debug
> >mode. I saw some body asked the same question some times ago. The
> >problem is someting about MCVC 1.52 does not initialize "some"
> >variables.
> >I have check microsoft knowledge base but I can't find any help.
> >Is their a solution to it? Or what type of varaibles that I need to
> >initialize?
> >
> >
-----From: "Rhodes, Brad"
Terrifying? This is not terrifying. If you expect that your debug
version of
from any compiler tool is going to behave the same as the release mode
then you will be greatly surprised. Ever since the earliest days of C
debug
versions and release versions of software have behaved differently.
This is
almost always due to ill behaved memory handling in your own code. It
is
sometimes related to ill behaved memory handling in library code.
I am not sure what variables will need to be initialized to get MFC
running
in release mode. I have several medium to large apps that run in retial
just fine. Just selected release in the Options->Project window. Once
all
of the memory bugs are worked out of my code everything works great.
>>----------
>>From: P. Senthil[SMTP:senthilp@geocities.com]
>>Sent: Tuesday, December 03, 1996 11:36 PM
>>To: mfc-l@netcom.com
>>Subject: Re: Released app version of msvc 1.52 gives GPF.
>>
>>You've hit upon one the most terrifying problems in VC++.
>>
>>To provide memory diagnostics during debug mode, MFC defines certain
>>extra things which are absent in the release mode. So generally there is
>>a GPF in release mode.
>>
>>The new operator allocates 512 odd bytes more in Debug mode than in
>>Release mode. So if you take care of your allocations, then there should
>>be no problem.
>>
>>Yoong Hor Meng wrote:
>>>
>>> Postage paid by:
>>> [Image]
>>> Catalog of the Internet
>>>
>>> ---------------------------------------------------------------
>>>
>>> Environment: VC++ 1.52 Windows 3.1
>>>
>>> The application I am writing gives GPF in released mode but not in debug
>>> mode. I saw some body asked the same question some times ago. The
>>> problem is someting about MCVC 1.52 does not initialize "some" variables.
>>> I have check microsoft knowledge base but I can't find any help.
>>> Is their a solution to it? Or what type of varaibles that I need to
>>> initialize?
>>
>>--
>>P. Senthil
>>-----------------------------------------------------------------------
>>1, 7th Avenue (West),
>>7th Main Road,
>>Dhandeeswaram Nagar,
>>Velachery,
>>MADRAS - 600 042.
>>
>>Mail: senthilp@geocities.com
>>
>>Homepage: www.geocities.com/SiliconValley/Heights/6504
>>
-----From: "Kenneth A. Argo"
Of course this is true !
In DEBUG build areas of memory which hold variables of all types it =
initialized to 0s. In release builds the memory of these variables =
contains whatever was in memory at the time the variable was created. =
You should either wrap your structures in a class and have a ctor =
initialize the members, or zero out the entire structure using something =
like memset().
Ken
----------
From: Grant Shirreffs (Great Elk)[SMTP:Grant.S@greatelk.com]
Sent: Tuesday, December 03, 1996 2:26 PM
To: mfc-l
Subject: RE: Released app version of msvc 1.52 gives GPF.
I'm not sure which initialisation problems you are referring to
specifically, but I have found a few times that the MSVC 1.5 generates
strange code in release mode when you try to initialise part of a
structure. For example:
OPENFILENAME ofn=3D{sizeof(ofn)};
causes problems in release.
To find any more than that, you'd need to give more information.
>----------
>From: Yoong Hor Meng
>Sent: Monday, 02 December 1996 7:04 PM
>To: mfc-l@netcom.com
>Subject: Released app version of msvc 1.52 gives GPF.
>
>Environment: VC++ 1.52 Windows 3.1
>
>The application I am writing gives GPF in released mode but not in
>debug
>mode. I saw some body asked the same question some times ago. The
>problem is someting about MCVC 1.52 does not initialize "some"
>variables.
>I have check microsoft knowledge base but I can't find any help.
>Is their a solution to it? Or what type of varaibles that I need to
>initialize?
>
>
Mao Zhihong -- maozhihong@hotmail.com
Saturday, December 07, 1996
[Mini-digest: 2 responses]
Hi,
Make sure you didn't put some importance codes in ASSERT(...) or #ifdef
_DEBUG ... #endif, these code will ignored in release mode.
You can change ASSERT(...) to VERIFY(...) if you really want to verify
a assertion any way.
hope it will helpful.
Yours
Mao
Yoong Hor Meng wrote:
>
> Postage paid by:
> [Image]
> Catalog of the Internet
>
> ---------------------------------------------------------------
>
> Environment: VC++ 1.52 Windows 3.1
>
> The application I am writing gives GPF in released mode but not in
debug
> mode. I saw some body asked the same question some times ago. The
> problem is someting about MCVC 1.52 does not initialize "some"
variables.
> I have check microsoft knowledge base but I can't find any help.
> Is their a solution to it? Or what type of varaibles that I need to
> initialize?
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Mao Zhihong ( Robert Mao ) DreamyRainbow Software Studio
Voc/Fax : 86-25-5408086
E-Mail : maozhihong@hotmail.com mao@seu.edu.cn
URL : http://seic3.seu.edu.cn/~mao
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-----From: "Tom Arne Trovatn"
----------
> From: David Lowndes
> To: 'mfc-l@netcom.com'
> Subject: RE: Released app version of msvc 1.52 gives GPF.
> Date: Wednesday, December 04, 1996 10:50 AM
>
> >The application I am writing gives GPF in released mode but not in debug
> mode. I saw some body asked the same question some times ago. The
> problem is someting about MCVC 1.52 does not initialize "some"
> variables.
> I have check microsoft knowledge base but I can't find any help.
> Is their a solution to it? Or what type of varaibles that I need to
> initialize?
> <
>
> You can debug your release version to find the problems if you change
> the options to include the debug information (Compiler - Debug Options,
> & Linker - Output - Generate Debugging Information).
>
> Dave
I think that the "some variables" that was mentioned is the fact that in
debug mode the compiler initializes all variables. So if you have any
uninitialized variables in your program the problems will not show up until
you do a build in Release mode.
Tom Arne
Alasdair Tompson -- trustpro@nildram.co.uk
Tuesday, December 10, 1996
[Mini-digest: 3 responses]
>-----From: Patrice Buriez
>
>Hi Yoong,
>
>>> The application I am writing gives GPF in released mode but not in debug
>>> mode. I saw some body asked the same question some times ago. The
>>> problem is someting about MCVC 1.52 does not initialize "some" variables.
>>> I have check microsoft knowledge base but I can't find any help.
>>> Is their a solution to it? Or what type of varaibles that I need to
>>> initialize?
>
I may have been the person who asked a similar question a while ago! Thank
you Patrice for your most comprehensive and useful answer to Yoong's
question. I have printed it out and shall keep it for future reference. It
has helped me to narrow down my particular problem which is caused when I
call a function in a DLL which returns a pointer to a char*. Using
AfxMessageBox() I have discovered that following this call (in the release
version of the application) the contents of the local variables in the
calling function get shifted by 4 bytes! I am sure this is because of some
wrong assumption in my coding and would be most grateful if anyone could
point me to the answer.
-------------------------------------------------------
Alasdair Tompson, Trust Programming
Email: trustpro@nildram.co.uk
-------------------------------------------------------
-----From: Mike Blaszczak
At 10:33 12/7/96 +0800, Mao Zhihong wrote:
>-----From: "Tom Arne Trovatn"
>I think that the "some variables" that was mentioned is the fact that in
>debug mode the compiler initializes all variables.
No, it doesn't. This is a myth. This is an extremely common myth,
and I wish I knew how it got started.
The compiler, in reaction to _any_ compilation switch that you can give it,
does _not_ initialize unintialized variables for you.
If you link against debug builds of the C runtime libraries in _some_ versions
of Visual C++, or if you run your program under a process that has
identified itself with the operating system as the debugger, dynamically
allocated memory may be initialized to some recognizable value for you.
But the compiler does not initialize variables that you haven't intiialized
and that the language specification doesn't require to be initialized.
.B ekiM
http://www.nwlink.com/~mikeblas/
I'm afraid I've become some sort of speed freak.
These words are my own. I do not speak on behalf of Microsoft.
-----From: trustpro@nildram.co.uk (Alasdair Tompson)
Environment: VC++ 2.0 Windows 95
>-----From: Patrice Buriez
>
>Hi Yoong,
>
> The application I am writing gives GPF in released mode but not in debug
> mode. I saw some body asked the same question some times ago. The
> problem is someting about MCVC 1.52 does not initialize "some" variables.
> I have check microsoft knowledge base but I can't find any help.
> Is their a solution to it? Or what type of varaibles that I need to
> initialize?
>
I may have been the person who asked a similar question a while ago! Thank
you Patrice for your most comprehensive and useful answer to Yoong's
question. I have printed it out and shall keep it for future reference. It
has helped me to narrow down my particular problem which is caused when I
call a function in a DLL which returns a pointer to a char*. Using
AfxMessageBox() I have discovered that following this call (in the release
version of the application) the contents of the local variables in the
calling function get shifted by 4 bytes! I am sure this is because of some
wrong assumption in my coding and would be most grateful if anyone could
point me to the answer.
-------------------------------------------------------
Alasdair Tompson, Trust Programming
Email: trustpro@nildram.co.uk
-------------------------------------------------------
| Вернуться в корень Архива
|