Hello All,
I have developed a application which works fine in debug mode but crashes in
release mode…
Can anybody help me in this regards,
Giri
This e-mail has been sent to you courtesy of OperaMail, as a free service from
- Switch optimizations off one by one in the release build. This can be a
compiler bug (at least MSVC 5 had some). - Check your debug macros. Do not use:
#ifdef _DEBUG
#define MYMACRO(s)
#else
#define MYMACRO(s)
#endif
but use:
#ifdef _DEBUG
#define MYMACRO(s)
#else
#define MYMACRO(s) do {} while(0)
#endif
instead. If you have:
if( something )
{
something;
}
else
MYMACRO();
in your code, this will lead to the bug with the first style of macro
definitions.
Max
----- Original Message -----
From: “Girish”
To: “NT Developers Interest List”
Sent: Friday, September 29, 2000 2:43 AM
Subject: [ntdev] crashing the app in release version
> Hello All,
>
> I have developed a application which works fine in debug mode but crashes
in
> release mode…
>
> Can anybody help me in this regards,
> Giri
>
> ------------------------------------------------------------
> This e-mail has been sent to you courtesy of OperaMail, as a free
service from
> Opera Software, makers of the award-winning Web Browser, Opera. Visit
us at
> http://www.opera.com/ or our portal at: http://www.myopera.com/ Your free
e-mail
> account is waiting at: http://www.operamail.com/
> ------------------------------------------------------------
>
>
> —
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to $subst(‘Email.Unsub’)
>
> 2) Check your debug macros. Do not use:
#ifdef _DEBUG
#define MYMACRO(s)
> #else
> #define MYMACRO(s)
> #endif
>
> but use:
>
> #ifdef _DEBUG
> #define MYMACRO(s)
> #else
> #define MYMACRO(s) do {} while(0)
> #endif
>
> instead. If you have:
> if( something )
> {
> something;
> }
> else
> MYMACRO();
>
Better yet, always use ‘{’ and ‘}’ rather than naked if or else statements.
Mark Roddy
Windows 2000/NT Consultant
Hollis Technology Solutions
www.hollistech.com
There could be several possibilties
-
you have code in #ifdef DEBUG that doesn’t get compiled and executed for
release builds -
compiler optimizations may be screwing up some of your assumptions. For eg:-
make sure you declare pointers to areas of memory updated by your hardware
device as ‘volatile’. -
you can turn optimizations off function by function using #pragma
optimize(“”,OFF) and narrow down where the problem could be
Reply Separator
Subject: [ntdev] crashing the app in release version
Author: “NT Developers Interest List”
Date: 9/28/00 6:43 PM
Hello All,
I have developed a application which works fine in debug mode but crashes in
release mode…
Can anybody help me in this regards,
Giri
------------------------------------------------------------
This e-mail has been sent to you courtesy of OperaMail, as a free service
from
Opera Software, makers of the award-winning Web Browser, Opera. Visit us at
http://www.opera.com/ or our portal at: http://www.myopera.com/ Your free e-mail
account is waiting at: http://www.operamail.com/
------------------------------------------------------------
—
You are currently subscribed to ntdev as: rkoduri@s3.com
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Do you use _asm blocks in your app? There can be a problem, check these
blocks carefully to be sure you do not change registers which compiler uses
in optimization.
??: Girish[SMTP:xxxxx@operamail.com]
???: NT Developers Interest List
???: 29 ??? 2000 ?. 1:43
???: NT Developers Interest List
???: [ntdev] crashing the app in release version
Hello All,
I have developed a application which works fine in debug mode but crashes
in
release mode…
Can anybody help me in this regards,
Giri
This e-mail has been sent to you courtesy of OperaMail, as a free
service from
Opera Software, makers of the award-winning Web Browser, Opera. Visit us
at
http://www.opera.com/ or our portal at: http://www.myopera.com/ Your free
e-mail
account is waiting at: http://www.operamail.com/
You are currently subscribed to ntdev as: xxxxx@telecom.sins.ru
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
> From: “Maxim S. Shatskih”
>
> 2) Check your debug macros. Do not use:
>
> #ifdef _DEBUG
> #define MYMACRO(s)
> #else
> #define MYMACRO(s)
> #endif
>
> but use:
>
> #ifdef _DEBUG
> #define MYMACRO(s)
> #else
> #define MYMACRO(s) do {} while(0)
> #endif
>
> instead. If you have:
> if( something )
> {
> something;
> }
> else
> MYMACRO();
>
> in your code, this will lead to the bug with the first style of macro
> definitions.
Am I missing something here?
If we correct the typo by giving a parameter to the MYMACRO()
call, then both versions should compile correctly and result
in identical behaviour - if they don’t it’s due to a compiler
bug. The first version has the advantage of needing less typing!
I think its intention is more obvious, as well.
Regards,
jjf
> If we correct the typo by giving a parameter to the MYMACRO()
Sorry for a typo.
call, then both versions should compile correctly and result
in identical behaviour - if they don’t it’s due to a compiler
No.
The first one will be
if(…)
{
…
}
else
next operator.
The second one will be
if(…)
{
…
}
else
do {} while(0)
next operator.
In the first case, “next operator” will become an “else” branch. This was
not intended.
Max
You shoud use MYMACRO() as MYMACRO();
So the first one will be
if(…)
{
…
}
else
;
next operator.
The second one will be
if(…)
{
…
}
else
do {} while(0);
next operator.
The same functionality, isn’t it?
P.S. I prefer inline functions.
??: Maxim S. Shatskih[SMTP:xxxxx@storagecraft.com]
???: NT Developers Interest List
???: 29 ??? 2000 ?. 18:44
???: NT Developers Interest List
???: [ntdev] Re: crashing the app in release version
If we correct the typo by giving a parameter to the MYMACRO()
Sorry for a typo.
call, then both versions should compile correctly and result
in identical behaviour - if they don’t it’s due to a compiler
No.
The first one will be
if(…)
{
…
}
else
next operator.
The second one will be
if(…)
{
…
}
else
do {} while(0)
next operator.
In the first case, “next operator” will become an “else” branch. This was
not intended.
Max
You are currently subscribed to ntdev as: xxxxx@telecom.sins.ru
To unsubscribe send a blank email to $subst(‘Email.Unsub’)
Girish wrote:
Hello All,
I have developed a application which works fine in debug mode but crashes in
release mode…
Check your user-defined message handlers.
–
Marko
ICQ: 5990814
“It’s Chin Qu’s deadly sword. I’ll have to use Billy’s Jeet Kun Do style.”
– Bobby Lo
> From: “Maxim S. Shatskih”
>
> > both versions should compile correctly and result
> > in identical behaviour - if they don’t it’s due to a compiler
>
> No.
> The first one will be
>
> if(…)
> {
> …
> }
> else
> next operator.
>
> The second one will be
>
> if(…)
> {
> …
> }
> else
> do {} while(0)
> next operator.
>
> In the first case, “next operator” will become an “else” branch. This was
> not intended.
Not so. The code was (reformatted to take less space)
if( something ) something;
else MYMACRO();
with the options
#define MYMACRO()
#define MYMACRO() do {} while(0)
For these two cases the ‘else’ clause will become:
else ;
else do {} while(0);
In the first case, the else clause consists of a null statement;
in the second case it’s a do statement that does nothing once.
The two are logically identical, and a C compiler must generate
exactly equivalent code for these cases - a decent compiler will
produce identical binaries.
“do { … } while(0)” has its place in macros, but this isn’t it.
The main use is to generate multiple-statement expansions that
work correctly in most circumstances.
I can’t think of any problems which wouldn’t have been caught by
the compiler where one of these definitions causes a problem
and the other doesn’t. They’re both equivalent, and for my money
leaving it blank makes it more obvious that it’s doing nothing.