Valhalla Legends Forums Archive | C/C++ Programming | VS.NET 2003 Internal Compile Error

AuthorMessageTime
Mephisto
BNLSConnection.cpp
c:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\include\cassert(9) : fatal error C1001: INTERNAL COMPILER ERROR
        (compiler file 'msc1.cpp', line 2701)
         Please choose the Technical Support command on the Visual C++
         Help menu, or open the Technical Support help file for more information


Does anyone know what this is?
November 11, 2004, 11:11 PM
Skywing
That happens if the compiler crashes while trying to compile something.  Try working backwards from your most recent changes until you can find what caused it.
November 11, 2004, 11:15 PM
Mephisto
Figured it out.  It was an assertion I made to check for SOCKET_ERROR on WSASend, but I don't see why that would cause the compiler to crash like that.  Interesting...
November 12, 2004, 1:53 AM
Myndfyr
As I recall, an ASSERT statement is a macro.  Perhaps the code you had inside of the ASSERT() macro was causing the macro's internal parameterization code to fail?
November 12, 2004, 2:18 AM
Mephisto
[quote author=MyndFyre link=topic=9518.msg88553#msg88553 date=1100225925]
As I recall, an ASSERT statement is a macro.  Perhaps the code you had inside of the ASSERT() macro was causing the macro's internal parameterization code to fail?
[/quote]

assert(WSASend(
                 _Socket,
                 &WSASendBuffer,
                 WSASendBufferCount,
                 &dwBytes,
                 dwFlags,
                 &OverlappedSend,
                 cConnect->StaticSendCompletionRoutine
               ) == SOCKET_ERROR);


The use of overlapped send completion routines was just experimental.  There was really no use for it in my program, only for overlapped recv completion routines.  However, it was odd that this statement caused the error.
November 12, 2004, 2:33 AM
Skywing
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.
November 12, 2004, 3:11 AM
Mephisto
[quote author=Skywing link=topic=9518.msg88557#msg88557 date=1100229066]
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.
[/quote]

Hmm, I see.  I thought the only thing I should be careful of when just asserting a SOCKET_ERROR was WSA_IO_PENDING.  Additionally, SOCKET_ERROR is defined as: #define SOCKET_ERROR (-1) so why would a 0 return matter in this assertion?  :)
November 12, 2004, 3:20 AM
Skywing
[quote author=Mephisto link=topic=9518.msg88560#msg88560 date=1100229642]
[quote author=Skywing link=topic=9518.msg88557#msg88557 date=1100229066]
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.
[/quote]

Hmm, I see.  I thought the only thing I should be careful of when just asserting a SOCKET_ERROR was WSA_IO_PENDING.  Additionally, SOCKET_ERROR is defined as: #define SOCKET_ERROR (-1) so why would a 0 return matter in this assertion?  :)
[/quote]
Umm.. it would matter because your program would die with an assertion on a perfectly valid situation?
November 12, 2004, 3:27 AM
Mephisto
[quote author=Skywing link=topic=9518.msg88566#msg88566 date=1100230049]
[quote author=Mephisto link=topic=9518.msg88560#msg88560 date=1100229642]
[quote author=Skywing link=topic=9518.msg88557#msg88557 date=1100229066]
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.
[/quote]

Hmm, I see.  I thought the only thing I should be careful of when just asserting a SOCKET_ERROR was WSA_IO_PENDING.  Additionally, SOCKET_ERROR is defined as: #define SOCKET_ERROR (-1) so why would a 0 return matter in this assertion?  :)
[/quote]
Umm.. it would matter because your program would die with an assertion on a perfectly valid situation?
[/quote]

Note:  I was just experimenting with overlapped I/O for sending data.  Also, if it returned 0 it wouldn't die because SOCKET_ERROR isn't 0.  Unless I'm missing something here?
November 12, 2004, 6:25 AM
Maddox
[quote author=Mephisto link=topic=9518.msg88585#msg88585 date=1100240708]
Note:  I was just experimenting with overlapped I/O for sending data.  Also, if it returned 0 it wouldn't die because SOCKET_ERROR isn't 0.  Unless I'm missing something here?
[/quote]

ASSERT assumes that zero is an error, causing your program to die.
November 12, 2004, 7:01 AM
Myndfyr
[quote author=Mephisto link=topic=9518.msg88585#msg88585 date=1100240708]
[quote author=Skywing link=topic=9518.msg88566#msg88566 date=1100230049]
[quote author=Mephisto link=topic=9518.msg88560#msg88560 date=1100229642]
[quote author=Skywing link=topic=9518.msg88557#msg88557 date=1100229066]
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.
[/quote]

Hmm, I see.  I thought the only thing I should be careful of when just asserting a SOCKET_ERROR was WSA_IO_PENDING.  Additionally, SOCKET_ERROR is defined as: #define SOCKET_ERROR (-1) so why would a 0 return matter in this assertion?  :)
[/quote]
Umm.. it would matter because your program would die with an assertion on a perfectly valid situation?
[/quote]

Note:  I was just experimenting with overlapped I/O for sending data.  Also, if it returned 0 it wouldn't die because SOCKET_ERROR isn't 0.  Unless I'm missing something here?
[/quote]

1,) WSASend returns something besides SOCKET_ERROR.
2.) Computer cmp's returned result to SOCKET_ERROR.
3.) Evaluation is 0.
4.) Computer jz's to the assert() function.
November 12, 2004, 7:41 AM
Arta
[quote author=Mephisto link=topic=9518.msg88555#msg88555 date=1100226783]
assert(WSASend(
                _Socket,
                &WSASendBuffer,
                WSASendBufferCount,
                &dwBytes,
                dwFlags,
                &OverlappedSend,
                cConnect->StaticSendCompletionRoutine
              ) == SOCKET_ERROR);

[/quote]

As people have pointed out, I think you meant != SOCKET_ERROR, but even so: This is a very bad way to assert something. If you compiled that in release mode it would remove the assert statement, and your WSASend along with it!

If you need to assert the return value of a function, save it in a variable and do your assertion on that -- I wouldn't do that either, though. It's far better with this kind of thing to do some proper error checking, and report the error to the user if there is one. Mostly, I use assertions just to make sure I didn't pass a NULL pointer to a function by mistake, or similar.
November 12, 2004, 8:38 AM
Mephisto
Thanks everyone.  :)
November 12, 2004, 6:28 PM

Search