Why the results of debug and release version is different.

[bantamweight]

Hi,
I create a project with vs2005 (both c++ and c# are used, sames the
problem is about c++) and it working well in Debug version but the
result is wrong in Release version. I checked again and again and no
difference of logic is found between two versions. I'm confused and
don't known how to correct it. Is there anyone encountered similar
deed? Any tips is wellcome.

Regards.

Bai Xiaoliang.

 

[Phlip]

bantamweight wrote;

I create a project with vs2005 (both c++ and c# are used, sames the
problem is about c++) and it working well in Debug version but the
result is wrong in Release version. I checked again and again and no
difference of logic is found between two versions. I'm confused and
don't known how to correct it. Is there anyone encountered similar
deed? Any tips is wellcome.

You have a bug. The bug has different symptoms in both builds.

Either post some code, or add unit tests to your code, or write it again
without the bug (not a joke), or post this question to
.

 

[Markus Grueneis]

Hi,
I create a project with vs2005 (both c++ and c# are used, sames the
problem is about c++) and it working well in Debug version but the
result is wrong in Release version. I checked again and again and no
difference of logic is found between two versions. I'm confused and
don't known how to correct it. Is there anyone encountered similar
deed? Any tips is wellcome.

You maybe misused the assert() macro (aka ASSERT, _ASSERTE or whatever
your compiler provides you additionally).

Or maybe you have used some LOG macro, which is defined differently for
_DEBUG and NDEBUG preprocessor options?

This way the logic _looks_ the same, but it isn't. Some tip for
debugging: try to find out _when_ the error occurs. This is simple
with some traces, it's probably much work with single-step-debugging,
though. Then you should not have to search all the sources, but just
look at the last correct function.


best regards,
-- Markus

 

[Default User]

Hi,
I create a project with vs2005 (both c++ and c# are used, sames the
problem is about c++) and it working well in Debug version but the
result is wrong in Release version.

A common behavior with debug versions is to set automatic variables,
something that's not required by the standard and is usually not done
in release modes (for whatever "debug" and "release" modes mean in a
particular implementation).

You mave have an uninitialized variable somewhere. It's hard for us to
tell without code. Reduce it to the smallest possible program that
still demonstrates the problem and post it. In reducing it, you
pinpoint the error on your own.





Brian

 

[bantamweight]

Hi,
Thanks for all kindly answers.
The problem is caused by my negligence.
My solution including several projects, yesterday, I moved one header
file which including template classes from project A to B and corrected
implemention of the template classes. I only build the release verion
of the solution without clean solution first. Thus the wrong result is
gotten. And after clean the solution firstly before build the
solution(or rebuild), every thing is right.

Regard.

Bai Xiaoliang

 

[Ron Natalie]

You maybe misused the assert() macro (aka ASSERT, _ASSERTE or whatever
your compiler provides you additionally).

Or most likely he is using free'd or unitialized memory. In debug
mode the Visual Studio runtimes fills free'd and uninited memory with
a distinctive hex pattern. It also puts guard areas around memory
allocations. In release it doesn't do any of this which so you
can get quite different behavior.

 

[Markus Grueneis]

[...]

You maybe misused the assert() macro (aka ASSERT, _ASSERTE or whatever
your compiler provides you additionally).

Or most likely he is using free'd or unitialized memory. In debug
mode the Visual Studio runtimes fills free'd and uninited memory with
a distinctive hex pattern. It also puts guard areas around memory
allocations. In release it doesn't do any of this which so you
can get quite different behavior.

Yes, this has bitten me also several times when maintaining some old or
otherones code. Nothing less common than some buffer which is too
small, and just happened to not chrash because of.. pff... luck?

I've encountered similar problems when porting some code from vc6 to
vc8. The more aggressive optimization in the newer version sometimes
also brought some waiting buffer overflows to light, and then you just
sit there thinking "but that was said to be working for 3 years now!".


-- Markus