asked on C macro not working in release mode visual studio
Experts,
I am using the attached code snippet macros in our code for swapping bytes.
Problems i observed are:
1)when i give 8 byte value to SWAP_8BYTES(x) MACRO it is crashing. This is happening only for Release build in visual studio. Swap works fine for Debug build.
Is this because of any memory related issues? Please comment.
SWAP MACROS are:
#define SWAP_2BYTES(x) ((((x)&0xFF00)>>8) | (((x)&0x00FF)<<8))
#define SWAP_4BYTES(x) ( (SWAP_2BYTES( ((x)&0xFFFF0000)>>16) ) | ( (SWAP_2BYTES((x)&0x0000FFF
#define SWAP_8BYTES(x) ( (SWAP_4BYTES( ((x)&0xFFFFFFFF00000000)>>
I am using the attached code snippet macros in our code for swapping bytes.
Problems i observed are:
1)when i give 8 byte value to SWAP_8BYTES(x) MACRO it is crashing. This is happening only for Release build in visual studio. Swap works fine for Debug build.
Is this because of any memory related issues? Please comment.
SWAP MACROS are:
#define SWAP_2BYTES(x) ((((x)&0xFF00)>>8) | (((x)&0x00FF)<<8))
#define SWAP_4BYTES(x) ( (SWAP_2BYTES( ((x)&0xFFFF0000)>>16) ) | ( (SWAP_2BYTES((x)&0x0000FFF
#define SWAP_8BYTES(x) ( (SWAP_4BYTES( ((x)&0xFFFFFFFF00000000)>>
#define SWAP_2BYTES(x) ((((x)&0xFF00)>>8) | (((x)&0x00FF)<<8))
#define SWAP_4BYTES(x) ( (SWAP_2BYTES( ((x)&0xFFFF0000)>>16) ) | ( (SWAP_2BYTES((x)&0x0000FFFF) )<<16) )
#define SWAP_8BYTES(x) ( (SWAP_4BYTES( ((x)&0xFFFFFFFF00000000)>>32) ) | ( (SWAP_4BYTES((x)&0x00000000FFFFFFFF) )<<32) )
CProgrammingMicrosoft Legacy OS
Last Comment
srimallikarthik
ASKER
x is unsigned long long,
t_uint64 Temp1, Temp = 52;
crashing for the below line and attached image is the crash description.
Temp1 = SWAP_8BYTES(Temp);
Untitled.png
t_uint64 Temp1, Temp = 52;
crashing for the below line and attached image is the crash description.
Temp1 = SWAP_8BYTES(Temp);
Untitled.png
ASKER
the above piece of code works good in debug build of visual studio. it crashes in release mode.
That crash was because of an access violation. Are you sure it's the macro that causes it ?
Can you show the code that is using the macro ? Can you also indicate the line that the debugger refers to when the crash occurs ?
Can you show the code that is using the macro ? Can you also indicate the line that the debugger refers to when the crash occurs ?
ASKER
I feel this is because of marco, i tried replacing my swap macro with the attached code macro which i found in some article. It is working superb.. ( means no crash)
#define SwapEightBytes(data) \ ( (((data) >> 56) & 0x00000000000000FF) | (((data) >> 40) & 0x000000000000FF00) | \ (((data) >> 24) & 0x0000000000FF0000) | (((data) >> 8) & 0x00000000FF000000) | \ (((data) << 8) & 0x000000FF00000000) | (((data) << 24) & 0x0000FF0000000000) | \ (((data) << 40) & 0x00FF000000000000) | (((data) << 56) & 0xFF00000000000000) )
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Any idea why it works for the other macro i used ?
There's no way to tell without first knowing what causes the crash.
Just a feeling is often not good enough. Please try running the code in a debugger, and figure out where it crashes exactly. This assumes that your IDE allows you to run release code in a debugger heh. Alternatively, you can add some debugging output of your own to narrow it down to the exact line where it crashes.
Just a feeling is often not good enough. Please try running the code in a debugger, and figure out where it crashes exactly. This assumes that your IDE allows you to run release code in a debugger heh. Alternatively, you can add some debugging output of your own to narrow it down to the exact line where it crashes.
I made a simple test application with VS 2010 to test both macros:
With both DEBUG and RELEASE build I have no crash and the output is the same:
Temp1: 3746994889972252672
Temp2: 3746994889972252672
ZOPPO
#define SwapEightBytes(data) \
( (((data) >> 56) & 0x00000000000000FF) | (((data) >> 40) & 0x000000000000FF00) | \
(((data) >> 24) & 0x0000000000FF0000) | (((data) >> 8) & 0x00000000FF000000) | \
(((data) << 8) & 0x000000FF00000000) | (((data) << 24) & 0x0000FF0000000000) | \
(((data) << 40) & 0x00FF000000000000) | (((data) << 56) & 0xFF00000000000000) )
#define SWAP_2BYTES(x) ((((x)&0xFF00)>>8) | (((x)&0x00FF)<<8))
#define SWAP_4BYTES(x) ( (SWAP_2BYTES( ((x)&0xFFFF0000)>>16) ) | ( (SWAP_2BYTES((x)&0x0000FFFF) )<<16) )
#define SWAP_8BYTES(x) ( (SWAP_4BYTES( ((x)&0xFFFFFFFF00000000)>>32) ) | ( (SWAP_4BYTES((x)&0x00000000FFFFFFFF) )<<32) )
int _tmain(int argc, _TCHAR* argv[])
{
unsigned __int64 Temp1, Temp2, Temp = 52;
Temp1 = SwapEightBytes( Temp );
Temp2 = SWAP_8BYTES( Temp );
std::cout << "Temp1: " << Temp1 << std::endl;
std::cout << "Temp2: " << Temp2 << std::endl;
return 0;
}
With both DEBUG and RELEASE build I have no crash and the output is the same:
Temp1: 3746994889972252672
Temp2: 3746994889972252672
ZOPPO
BTW: how is 't_uint64' defined? It's not a standard VC++ type ...
ASKER
Defined as below:
typedef unsigned long long t_uint64;
typedef unsigned long long t_uint64;
ok, this doesn't make a difference in my test app, works with that typedef too in both RELEASE and DEBUG.
To figure out what causes the crash, can you please do what I explained in http:#35793257 ?
Just to make it easier to single out the true reason for the crash: http://msdn.microsoft.com/en-us/library/fsk896zz%28v=VS.100%29.aspx ("How to: Debug a Release Build")
ASKER
Though comments didn't point out the actual solution for the problem, it helped in resolving the issue.
Thanks a lot.
Thanks a lot.
ASKER
Experts,
Thanks for the comments,
Problem was because of the compiler optimization which lead our macro go mad in release build.
Thanks for the comments,
Problem was because of the compiler optimization which lead our macro go mad in release build.
>> Though comments didn't point out the actual solution for the problem, it helped in resolving the issue.
So, what was the issue ?
I'm sure it wasn't in the macro that you showed, as I told you in http:#35793073.
We could have assisted you better if you would have given us the extra information I asked for in that same post :)
So, what was the issue ?
I'm sure it wasn't in the macro that you showed, as I told you in http:#35793073.
We could have assisted you better if you would have given us the extra information I asked for in that same post :)
>> Problem was because of the compiler optimization which lead our macro go mad in release build.
Could you clarify that ? How did it go mad ? And how did it cause an access violation ? That doesn't make much sense, since the macro isn't accessing any memory.
Could you clarify that ? How did it go mad ? And how did it cause an access violation ? That doesn't make much sense, since the macro isn't accessing any memory.
ASKER
What i did is, just disabled the compiler optimization from "maximum speed" to "disabeld" in project settings and built the project in release build. IT WORKED(no crash). So i concluded its because of compiler optimization.
And YES, it is because of macro (optimization). The another macro which i mentioned swapeightbytes(x) is not calling another macros inside. It is expanded completely at compile time unlike the other macro which expands further while preprocessing which created problem because of optimization.
It's surprising that VC++ would optimize at the preprocessing stage, because that doesn't make a lot of sense.
Disabling optimization indicates that it is indeed likely a problem related to the way VC++ optimizes the code. However, that doesn't mean the problem had anything to do with the macro. It still seems highly unlikely that the access violation was caused by the macro.
If I were you, I'd investigate this a bit further (with our help if you want), to make sure that the issue is actually resolved, and not just hidden. I assume it's not an option for you to keep optimization disabled for the release target, so that's a further reason to track down the root cause.
Disabling optimization indicates that it is indeed likely a problem related to the way VC++ optimizes the code. However, that doesn't mean the problem had anything to do with the macro. It still seems highly unlikely that the access violation was caused by the macro.
If I were you, I'd investigate this a bit further (with our help if you want), to make sure that the issue is actually resolved, and not just hidden. I assume it's not an option for you to keep optimization disabled for the release target, so that's a further reason to track down the root cause.
@srimallikarthik: Which version of Visual Studio do you use? I built my test app with VS 2010 with all speed-optimizations turned on and everything works fine ...
ASKER
i am using VS2008
i will check my same on VS2010. lets see.
As you mentioned it seems unlikely that access violation occurs. I didn't get time to dig into that :(.
i will check my same on VS2010. lets see.
As you mentioned it seems unlikely that access violation occurs. I didn't get time to dig into that :(.
ASKER
@Infinity08: As you mentioned it seems unlikely that access violation occurs becoz of the way compiler optimizes.
I will find some time and dig into this.
thanks for the comments.
I will find some time and dig into this.
thanks for the comments.
What kind of crash are you talking about ?