- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!!
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!!
Link Copied
5 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Also, what "Program" was named in the error message?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!!!
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!!!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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:
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.
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
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.

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page