Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Debug Assertion Failed!

j_fan
Beginner
1,253 Views
When Itry to build a project with VS2010 & IVF12, i encountered a "Debug Assertion Failed!" error:

Program: ...
File f:\\dd\\vctools\\crt_bld\\self_x86\\crt\\src\\winsig.c
Line 417

Expression: ("Invalid signal or error", 0)


The program works well in VS2005 & IVF11.

Is it because of the VS2010? how should I solve it? Many thanks!!
0 Kudos
5 Replies
mecej4
Honored Contributor III
1,253 Views
This appears to be an error with the compiler/MSVC tools. However, this error is not seen with every source code, so it is necessary for you to provide a short example of source code (and project files, if appropriate) to enable one to reproduce the error that you saw.
0 Kudos
Steven_L_Intel1
Employee
1,253 Views
Also, what "Program" was named in the error message?
0 Kudos
j_fan
Beginner
1,253 Views
Thank you for your replies!

The crash occurs in dbghook.c, after an ENTRY statement.
Here it is.

__declspec(noinline)
void __cdecl _CRT_DEBUGGER_HOOK(int _Reserved)
-> {
/* assign 0 to _debugger_hook_dummy so that the function is not folded in retail */
(_Reserved);
_debugger_hook_dummy = 0;
}


Should I avoid the ENTRY? The program runs fine with VS2005.

To Steve: the "Program" is the route of the .exe file: Program: D:\...\3d_test\Debug\3d_test.exe.

Many thanks!!!
0 Kudos
Steven_L_Intel1
Employee
1,253 Views
Ok - so the error occurs when you run the program, not when you build it. The messge you show, with reference to dbghook.c, is not really relevant. It simply indicated an unhandled exception. There is probably a console window hidden behind the VS window with the real error message.

ENTRY is still legal and can be useful, but you have to make sure you follow the rules. My guess is that you didn't. The main rule is that you must not reference a dummy argument if that name was not in the dummy argument list of the entry point through which you entered. For example:

[fortran]subroutine sub (a,b)
real :: a,b
entry foo (a)
print *, a+b
end[/fortran]

If you call entry FOO, only passing a, the print is not legal because b was referenced and not in FOO's dummy argument list.

Many years ago, it was common to see code that took advantage of the way some compilers processed ENTRY statements - programs would first call one entry point, passing some arguments, and then call another with the expectation that the arguments were "remembered" from the earlier call. This is not legal and can lead to errors.
0 Kudos
TimP
Honored Contributor III
1,253 Views
There were pre-standard versions of ENTRY where the argument list was not re-stated at the ENTRY point, but was taken to duplicate the SUBROUTINE argument list. In that case, the CALL had to have the full argument list.
Even when the ENTRY follows the f77 rules, it's common to see an expectation of all variables SAVE but with the SAVE omitted. That also violates the standard.
0 Kudos
Reply