Release/Build Problem - Adding a pointer variable solves it???

[Saurabh Aggrawal]

Hi,

I have made a dll and it is working fine in the debug build (as
expected) but when I run it in the release build it is working
strangely.
For example, the dll saves the 10 properties on the exit to a .txt file
and when it get loaded again these properties are read from the text
file and shown on the user interface.

Dll can save the values to the text file correctly for both debug and
release builds.
But the dll could not read the values of these properties in the
release build somehow. Btw it is reading values fine in debug build.

So let say I have 10 properties namely... A, B, C, D, E, F, G,H, I ,J
then I could read A B C D F G I J from the text file but others are
lost in the way.

One unique thing I have observed is that adding a pointer in the code:

wchar_t str[256];

solves this problem. I am not using "str" anywhere in the code.

I have initialized the variables properly and also done the alignment
of the structures "#pragma pack(8)". I tested the code on prefast and
no errors are there. I have also turned of the optimizer.

The only way I am able to run the Dll correctly without adding this
variable is by keeping the debug information in the Release Dll. I
don't want to keep the debug information in the release dll as it is
increasing the size of the dll.

Could you please suggest me the reason for this strange behavior?

Respects,
Saurabh Aggrawal


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[deane_gavin]

Hi,

I have made a dll and it is working fine in the debug build (as
expected) but when I run it in the release build it is working
strangely.
For example, the dll saves the 10 properties on the exit to a .txt file
and when it get loaded again these properties are read from the text
file and shown on the user interface.

Dll can save the values to the text file correctly for both debug and
release builds.
But the dll could not read the values of these properties in the
release build somehow. Btw it is reading values fine in debug build.

So let say I have 10 properties namely... A, B, C, D, E, F, G,H, I ,J
then I could read A B C D F G I J from the text file but others are
lost in the way.

One unique thing I have observed is that adding a pointer in the code:

wchar_t str[256];

solves this problem. I am not using "str" anywhere in the code.

I have initialized the variables properly and also done the alignment
of the structures "#pragma pack(8)". I tested the code on prefast and
no errors are there. I have also turned of the optimizer.

The only way I am able to run the Dll correctly without adding this
variable is by keeping the debug information in the Release Dll. I
don't want to keep the debug information in the release dll as it is
increasing the size of the dll.

Could you please suggest me the reason for this strange behavior?

Difficult without seeing your code. Can you post it, following the
instructions here

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.8

keeping the windows and dll specifics to a minimum.

It may turn out to be a C++ problem, perhaps undefined behaviour in
your code that is leading to different behaviour in the two builds. On
the other hand, it may turn out to be a windows dll-specific problem,
in which case you will want to ask in a group suggested by this FAQ

http://www.parashift.com/c++-faq-lite/how-to-post.html#faq-5.9

but without seeing the code, who knows.

Gavin Deane


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Chimp]

These problems are difficult to solve remotely, but this may help;

Check if you are using the debug runtime library (/MDd,/MTd or /MLd )
for the debug build, is so then change this to use the non debug
runtimes "/MD,/MT or /MLd", if after this you notice the same problem
with the debug build as you did with the relase one, then the problem
is most likely some form of memory corruption.

The debug CRT (/MDd,/MTd or /MLd) has a lot of usefull features that
you can turn on to trace memory corruptions. See MSDN on
_CrtSetDbgFlag.

Hope this helps


[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Karl Heinz Buchegger]

solves this problem. I am not using "str" anywhere in the code.

I have initialized the variables properly and also done the alignment
of the structures "#pragma pack(8)". I tested the code on prefast and
no errors are there. I have also turned of the optimizer.

The only way I am able to run the Dll correctly without adding this
variable is by keeping the debug information in the Release Dll. I
don't want to keep the debug information in the release dll as it is
increasing the size of the dll.

Could you please suggest me the reason for this strange behavior?

No, you provided to little information especially you don't provide code.
Nothing we can look at and point with fingers at it and say: here
is your problem.

But: Watch out for uninitialized variables, watch out for buffer
overflows. These are two places where debug builds often differ
from release builds.

BTW:

One unique thing I have observed is that adding a pointer in the code:

wchar_t str[256];

You have not added a pointer. You added an array. An array is *not* a pointer.
The fact that you got this wrong brings up thoughts about a whole family of
things you might have done wrong. So post code!

--
Karl Heinz Buchegger
(e-mail address removed)

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 

[Gianni Mariani]

Hi,

I have made a dll and it is working fine in the debug build (as
expected) but when I run it in the release build it is working
strangely.
For example, the dll saves the 10 properties on the exit to a .txt file
and when it get loaded again these properties are read from the text
file and shown on the user interface.

Not much help we can give you. It's way too hard to know what might be
going on.

Check all the assert() calls to see if there are any expressions which
need to be run even in release mode.

[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]