How to let the program output runtime error information in C++ code?

Zhanghong_T_ · ‎07-08-2014

Dear all,

I have the C++ dynamic linked library built by VS2012+Intel C++ 14.0, the dynamic linked library is called by Fortran main program.

Currently there are some problems in the C++ code and I need to locate it. However, the bug can't be reproduced in Debug mode but in Release mode, I can't get to know where the crash happened. I have set /Zi option in 'C/C++' and /DEBUG option in 'Linker', but the output message is as follows:

forrtl: severe (157): Program Exception - access violation

Image PC Routine Line Source

CSGlib.dll         000007FEEF57DF1E Unknown               Unknown Unknown

CSGlib.dll         000007FEEF57DB5F Unknown               Unknown Unknown

CSGlib.dll         000007FEEF57D78D Unknown               Unknown Unknown

fem.exe            000000013FD6F26E ELEMENT_mp_LOCALM       20494 datatype.f90

fem.exe 000000013FDE82ED ELEMENT_mp_TESTME 20389 datatype.f90

fem.exe            000000013FF1DFEF LOGGING3D..0             4600 main.f90

fem.exe            000000013FEFE700 MAIN_PARALLEL             240 main.f90

fem.exe            000000013FE8C02D MAIN__                     39 main.f90

fem.exe            00000001429799B6 Unknown               Unknown Unknown

fem.exe            0000000140950D88 Unknown               Unknown Unknown

kernel32.dll       000000007775652D Unknown               Unknown Unknown

ntdll.dll          000000007798C541 Unknown               Unknown Unknown

where fem.exe is the Fortran main program and CSGlib.dll is the C++ dynamic linked library. I can get to know the crash location of Fortran code but can't get to know the location of C++ code.

What do I miss in project settings?

original post is here:

https://software.intel.com/en-us/forums/topic/517867

Thanks,

Zhanghong Tang

Zhanghong_T_ · ‎07-08-2014

Progress: I tried to check the PDB files generated by the command

DUMPBIN /HEADERS fem.pdb

and

DUMPBIN /HEADERS csglib.pdb

The following errors displayed:

Dump of file fem.pdb
fem.pdb : warning LNK4048: Invalid format file; ignored

Summary

Dump of file csglib.pdb
csglib.pdb : warning LNK4048: Invalid format file; ignored

Summary

What settings should I add to generate valid format files?

Thanks

IanH · ‎07-08-2014

Dumpbin (as far as I am aware) does not read PDB files - hence the errors you see in your follow up post.

Try specifying the /traceback option for the C++ compiler when you build the DLL. That, plus /Zi, should give a reasonably specific location.

Zhanghong_T_ · ‎07-08-2014

Hi IanH,

Thank you very much for your kindly reply. I have already specified the options /traceback and /Zi, but the output message still didn't give the location that crash happened in C++ code.

Is there anything that I missed?

Thanks

IanH · ‎07-08-2014

What other options are you using when you compile the DLL?

An example that works for me:

// crash-c.cpp
#include <cstdlib>

void c_two();
void c_three();

extern "C" void __declspec(dllexport) c_one()
{
  c_two();
}

void c_two()
{
  c_three();
}

void c_three()
{
  char *p = NULL;
  *p = 1;  // boom
}

! crash-fortran.f90
PROGRAM Crash
  IMPLICIT NONE
  CALL f_one
CONTAINS
  SUBROUTINE f_one()
    CALL f_two
  END SUBROUTINE f_one
  
  SUBROUTINE f_two()
    CALL f_three
  END SUBROUTINE f_two
  
  SUBROUTINE f_three()
    INTERFACE
      SUBROUTINE c_one() BIND(C,NAME='c_one')
        IMPLICIT NONE
      END SUBROUTINE c_one
    END INTERFACE
    CALL c_one
  END SUBROUTINE f_three
END PROGRAM Crash

>icl /LD /traceback /Zi "crash-c.cpp"
...
>ifort /traceback /Zi "crash-fortran.f90" "crash-c.lib"
...
>crash-fortran.exe
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
crash-c.dll        000007FEF6031040  ?c_three@@YAXXZ            19  crash-c.cpp
crash-c.dll        000007FEF6031024  ?c_two@@YAXXZ              13  crash-c.cpp
crash-c.dll        000007FEF603100F  c_one                       8  crash-c.cpp
crash-fortran.exe  000000013F4E1062  CRASH_ip_F_THREE           19  crash-fortran.f90
crash-fortran.exe  000000013F4E104D  CRASH_ip_F_TWO             10  crash-fortran.f90
crash-fortran.exe  000000013F4E1038  CRASH_ip_F_ONE              6  crash-fortran.f90
crash-fortran.exe  000000013F4E101E  MAIN__                      3  crash-fortran.f90
crash-fortran.exe  000000013F57EFCE  Unknown               Unknown  Unknown
crash-fortran.exe  000000013F556173  Unknown               Unknown  Unknown
kernel32.dll       00000000770559ED  Unknown               Unknown  Unknown
ntdll.dll          000000007718C541  Unknown               Unknown  Unknown

Zhanghong_T_ · ‎07-09-2014

Dear IanH,

Thank you very much for your kindly reply.

Instead of building program by command line, I created the project by VS2012. I attached a sample project which can reproduce my problem. Could you please help me to take a look at it?

Thanks,

Zhanghong Tang

Zhanghong_T_ · ‎07-09-2014

Dear IanH,

I forgot to add /traceback option in project settings. Now I added this option and updated the project. It seems that Debug version is OK but Release version is still not correct located. Could you please help me to take a look at it?

Thanks

pbkenned1 · ‎07-09-2014

Hello Zhanghong,

Thanks for posting crashtest.zip. Let me do some debugging, and I'll follow up here. Since this seems more like a Fortran issue than C++ issue, I will close the original post https://software.intel.com/en-us/forums/topic/517867 on the C++ Forum.

Patrick

Zhanghong_T_ · ‎07-09-2014

Dear Patrick,

Thank you very much for your kindly reply.

Are there any wrong settings in my project?

Thanks

Zhanghong_T_ · ‎07-10-2014

Dear IanH,

How to build a x64 version DLL by command line?

I tried to test your example by

icl /LD /traceback /Zi /MACHINE:X64 "crash-c.cpp"

but the compiler displayed the following error:

icl: command line warning #10006: ignoring unknown option '/MACHINE:X64'

Thanks

IanH wrote:

What other options are you using when you compile the DLL?

An example that works for me:

// crash-c.cpp
#include <cstdlib>

void c_two();
void c_three();

extern "C" void __declspec(dllexport) c_one()
{
  c_two();
}

void c_two()
{
  c_three();
}

void c_three()
{
  char *p = NULL;
  *p = 1;  // boom
}

! crash-fortran.f90
PROGRAM Crash
  IMPLICIT NONE
  CALL f_one
CONTAINS
  SUBROUTINE f_one()
    CALL f_two
  END SUBROUTINE f_one
  
  SUBROUTINE f_two()
    CALL f_three
  END SUBROUTINE f_two
  
  SUBROUTINE f_three()
    INTERFACE
      SUBROUTINE c_one() BIND(C,NAME='c_one')
        IMPLICIT NONE
      END SUBROUTINE c_one
    END INTERFACE
    CALL c_one
  END SUBROUTINE f_three
END PROGRAM Crash

>icl /LD /traceback /Zi "crash-c.cpp"
...
>ifort /traceback /Zi "crash-fortran.f90" "crash-c.lib"
...
>crash-fortran.exe
forrtl: severe (157): Program Exception - access violation
Image              PC                Routine            Line        Source
crash-c.dll        000007FEF6031040  ?c_three@@YAXXZ            19  crash-c.cpp
crash-c.dll        000007FEF6031024  ?c_two@@YAXXZ              13  crash-c.cpp
crash-c.dll        000007FEF603100F  c_one                       8  crash-c.cpp
crash-fortran.exe  000000013F4E1062  CRASH_ip_F_THREE           19  crash-fortran.f90
crash-fortran.exe  000000013F4E104D  CRASH_ip_F_TWO             10  crash-fortran.f90
crash-fortran.exe  000000013F4E1038  CRASH_ip_F_ONE              6  crash-fortran.f90
crash-fortran.exe  000000013F4E101E  MAIN__                      3  crash-fortran.f90
crash-fortran.exe  000000013F57EFCE  Unknown               Unknown  Unknown
crash-fortran.exe  000000013F556173  Unknown               Unknown  Unknown
kernel32.dll       00000000770559ED  Unknown               Unknown  Unknown
ntdll.dll          000000007718C541  Unknown               Unknown  Unknown

mecej4 · ‎07-10-2014

You need to use the proper command window (one which is configured to use IFort-x64), by choosing a command window shortcut with a name similar to "Intel 64 Visual Studio 2012 mode", under Intel Parallel Studio in the program menu.

Within that window, IanH's commands will work fine. You used the incorrect option /MACHINE:X64 in your command line. First of all, that is an option to the librarian (LIB) and linker (LINK) commands, not the compiler. Secondly, if you use the proper command window, this option is unnecessary.

jimdempseyatthecove · ‎07-10-2014

I do not know if this is pertinent or not.

When building a Release build from Visual Studio .AND. adding compiler options for debug line numbers (and likely traceback) the compiler will produce that information.

However, the Link options for Release build default to strip off all debug information.

In VS Solution property page for Linker, Debugging, set Generate Debug Info to Yes (/DEBUG)

Jim Dempsey

Zhanghong_T_ · ‎07-10-2014

Dear mecej4,

Thank you very much for your kindly reply.

I have already used that window, but the built DLL of my own program is wrong. I don't know why...

Zhanghong_T_ · ‎07-10-2014

Dear Jim,

Thank you very much for your kindly reply. I have already set that option as you said, but it seems that only Debug version shows the error information correctly.

Thanks

jimdempseyatthecove wrote:

I do not know if this is pertinent or not.

When building a Release build from Visual Studio .AND. adding compiler options for debug line numbers (and likely traceback) the compiler will produce that information.

However, the Link options for Release build default to strip off all debug information.

In VS Solution property page for Linker, Debugging, set Generate Debug Info to Yes (/DEBUG)

Jim Dempsey

pbkenned1 · ‎07-10-2014

Hello Zhanghong,

You said "only Debug version shows the error information correctly." Do you get any error information? When I build in Release mode, then do Debug > Start Debugging, I get trigger a breakpoint on newtest->crashtest(); That's not quite what I expected, but I do get a traceback (see attached).

As an aside, for simple coding errors like divide-by-zero, you should just be using Debug mode to track them down. It's can be much harder in Release mode, due to inlining, loop optimsations, etc.

Patrick

pbkenned1 · ‎07-10-2014

Just to emphasize what I said in my last post, you can trigger a breakpoint in the Release build on the actual divide-by-zero by disabling inlining in the DLL (Properties > C/C++ > Optimization > Inline Function Expansion > Disabled (/Ob0).

Patrick

Zhanghong_T_ · ‎07-10-2014

Dear Patrick,

Thank you very much for your kindly reply.

I just use the divide-by-zero to reproduce the crash problem and show that the crash problem can't be located in Release mode. I don't know what and where the crash problem is in my real code (the crash only happens in Release mode).

The option /Ob0 has successfully located the crash lines, but it still can't locate the crash location in my real program.

On the other hand, I also tried to test the command line by IanH, it can also locate the crash lines for the example without the option /Ob0.

Thanks

Zhanghong_T_ · ‎07-10-2014

Dear Patrick and Jim,

I also tried to build my own project in command line as follows:

icl /D "TETLIBRARY" /D "CARVE_USE_EXACT_PREDICATES" /D "CARVE_SYSTEM_BOOST" /D "CARVE" /D "WIN64" /D "NDEBUG" /D "_WINDOWS" /I".\CSGlib\mesh" /I".\CSGlib\mesh\include" /I"C:\Program Files (x86)\boost_1_54_0" /I"C:\Program Files (x86)\Intel\VTune Amplifier XE 2013\include" ".\CSGlib\*.cpp" ".\CSGlib\mesh\*.cxx" ".\CSGlib\mesh\lib\*.cpp" ".\CSGlib\mesh\common\*.cpp" ".\CSGlib\mesh\external\src\*.cpp" /LD /bigobj /traceback /fp:precise /Zc:wchar_t /Zi /O2 /MT /EHsc /Fo.\obj\ /Fe:"Z:\directional\for_debug\CSGlib.dll" /Fd:"Z:\directional\for_debug\CSGlib.pdb" /F10000000000

After successfully built, I run the executable (still built from VS2012 IDE), the following error message displayed:

fem.exe - Application Error

The application was unable to start correctly (0x000007b). Click OK to close the application.

Is there any missed options I have not added?

Thanks

Lorri_M_Intel · ‎07-11-2014

Try cutting back the pre-allocation size of the stack:

change /F10000000000 to something a bit smaller, and see if your executable will start up.

Zhanghong_T_ · ‎07-11-2014

Dear Lorri,

Thank you very much for your kindly reply. I also noticed that and I changed it to /F1000000000, the problem is solved.

Currently I can locate the problem by running my real program built from command line.

Thanks