• Welcome to Valhalla Legends Archive.
 

VS.NET 2003 Internal Compile Error

Started by Mephisto, November 11, 2004, 05:11 PM

Previous topic - Next topic

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?

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.

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...

MyndFyre

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?
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Mephisto

#4
Quote from: MyndFyre on November 11, 2004, 08:18 PM
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?

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.

Skywing

On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.

Mephisto

Quote from: Skywing on November 11, 2004, 09:11 PM
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.

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?  :)

Skywing

Quote from: Mephisto on November 11, 2004, 09:20 PM
Quote from: Skywing on November 11, 2004, 09:11 PM
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.

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?  :)
Umm.. it would matter because your program would die with an assertion on a perfectly valid situation?

Mephisto

Quote from: Skywing on November 11, 2004, 09:27 PM
Quote from: Mephisto on November 11, 2004, 09:20 PM
Quote from: Skywing on November 11, 2004, 09:11 PM
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.

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?  :)
Umm.. it would matter because your program would die with an assertion on a perfectly valid situation?

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?

Maddox

Quote from: Mephisto on November 12, 2004, 12:25 AM
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?

ASSERT assumes that zero is an error, causing your program to die.
asdf.

MyndFyre

Quote from: Mephisto on November 12, 2004, 12:25 AM
Quote from: Skywing on November 11, 2004, 09:27 PM
Quote from: Mephisto on November 11, 2004, 09:20 PM
Quote from: Skywing on November 11, 2004, 09:11 PM
On a partially related note, WSASend will return 0 if the send wasn't delayed, so that's an unwise assertion to make.

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?  :)
Umm.. it would matter because your program would die with an assertion on a perfectly valid situation?

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?

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.
QuoteEvery generation of humans believed it had all the answers it needed, except for a few mysteries they assumed would be solved at any moment. And they all believed their ancestors were simplistic and deluded. What are the odds that you are the first generation of humans who will understand reality?

After 3 years, it's on the horizon.  The new JinxBot, and BN#, the managed Battle.net Client library.

Quote from: chyea on January 16, 2009, 05:05 PM
You've just located global warming.

Arta

Quote from: Mephisto on November 11, 2004, 08:33 PM
assert(WSASend(
                 _Socket,
                 &WSASendBuffer,
                 WSASendBufferCount,
                 &dwBytes,
                 dwFlags,
                 &OverlappedSend,
                 cConnect->StaticSendCompletionRoutine
               ) == SOCKET_ERROR);


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.

Mephisto