OK in debug mode, crash in release mode ??

[plinius]

Hi,
I made a program which works fine when builded with:
microsoft vc6 compiler in debug mode
microsoft vc6 compiler in release mode
intel c++ 8.1 compiler in debug mode

but it crashes when I build it in
intel c++ 8.1 compiler in release mode ....

That's really annoying, because I can't search the error since it works fine in debug mode....
What can I do ??


Thanks .

[Maximillia_D_Intel]

Hi,

If you compile in release mode, but try adding -Zi (keep -O2)and creating a map file (-Fm I believe). This should allow you to find the particularfunction the crash occurs in. If you can't reproduce (perhaps -Zi makes the problem goaway), remove -Zi. If all you get is an address where the crash occurs, you should be able touse the map file to map the address to a particular function.

Once you have isolated to a function, you can continue isolating from there and hopefully roll up a testcase to file to Premier support so the team can fix. Hope this helps, of course the biggest help would be if the release build worked,so let me say that I appreciate your efforts and understand your annoyance. Weare dedicated to resolvingissues with our compiler and having isolated issues go a long way towards that end.

Best regards,

Max

[plinius]

Hi, and thanks for your replie.
I tried adding the /Zi , (which doesn't makes the problem go away), but when I trie to add /Fm , I allways have this error:

---------------------------
Format of decimal number 'm' is incorrect. It may only contain characters 0-9. It must be positive, the '+' prefix is optional. The maximum allowed decimal number is 4,294,967,295.
---------------------------

And the help of /Fm is:

/c compile to object (.obj) only, do not link
/S compile to assembly (.asm) only, do not link (*I)
/FA[cs] produce assembly file with optional code or source annotations
...
/Fm[file] name map file or directory

So I think I use it correctly...

Could you please provide me some more information on how to set the /Fm correctly, and how to read the generated file/location of the error ? (this is quite new to me, so sorry if I'm a bit slow).

"Once you have isolated to a function, you can continue isolating from there and hopefully roll up a testcase to file to Premier support" -> the cppfile with the error in is only 350 lines, so IF you can guarantee me not to "release" my code, I can send it to you personnaly (so, not "support at intel d com"... ). I hope you understand my caution.

[plinius]

Hello again.
I found another way to generate the mapfile (just clicking a checkbox in the link-tab) but:
In the mapfiles all teh adresses of the functions start with zeros (example: 000009fc), and when I want to trace into my error in the asm-listing , I first arrive at adress 77F65A58 , a msgbox says "unhandled exception in as.exe: 0xC0000005: Acces violation",
and, after I clicked away this box I jump to 00401AF0 (to some SSE/SSE2 instructions, I think...).

Sorry for the not so professional manner of describing what happens, but I'm not an asm-programmer, so don't know a lot about it....

[Maximillia_D_Intel]

In your map file, there should be a column denoted Rva+base. I believe these are the addresses to use.

If you perform a dumpbin /disasm as.exe, this should provide a disassembly listing that should correlate with the address in your map file. You should be able to figure out where the program is crashing (assuming it is crashing inside your program and not in some system library).

Regards,

Max

[plinius]

Thanks.
I followed your guide, and found that it is in a function where there CAN't be an error in...

What causes my problem in general (working debug - nonworking release) ??

What else can I do ?

Thanks for your help so far.

[plinius]

can I send you a "reduced sample program" ?? Or do you prefer not ??

Grtz

[Maximillia_D_Intel]

Hi,

There could be many causes to what you are seeing. It could be a bug in the compiler (exhibited during release mode compiles). It could be a problem in your code that is only exposed at higher levels of optimization. Until the problem is isolated, there is no way to say for certain.

If you have a reduced testcase that exhibits the issue, can I suggest that you file with Premier support. Communication through premier support is secure (only the necessary personal see the issue). In the reduction, hopefully you performed a binary search to limit the number of functions (when compiled under release mode) that are involved.

Are you familiar with the binary search technique for isolating issues?

Best regards,

Max

[plinius]

Hi,

"Are you familiar with the binary search technique for isolating issues?" ->No, sorry, I'm not...

About the Premier support, is it allso for the trialversion of the compiler, or only for customers ??

Thanks.
Plinius.

[Maximillia_D_Intel]

Binary search involves compiling half with an option set that works (for example, debug in your case) and half with an option set that fails. If the application fails, take the half and split it into half again (half compiled with the option that fails and half without). Continue the process until you find the smallest region of code that contains the issue. This process can be used for files in your project and than with functions in your project.

Max

[plinius]

Thanks, and where can I find a tutorial/explanation on how to do that (it doesn't seems that easy for me, on first sight ?!) .

[plinius]

searched a bit myself, but google isn't my best friend for the moment ..

[plinius]

fixed.
it was the /Qfsalign which caused the troubles. When I remove it it works fine.
Thx.