OK - I definitely appear to have caught it in the act.
Here's the assembly for the loop that calls WaitForRX():
511: if ( (DWORD)psThreadData == 0x00000001)
02CD1B7B cmp esi,ebx
I assume both the values of esi and ebx are 0x1 here.
02CD1B7D jne CommsRXThreadProc+45h (02cd1b81)
512: psThreadData->bTerminate = FALSE ;
The fact that *after* you check psThreadData to be 1, you access a member variable of it (effectively dereferencing it) should immediately lead to an exception (if run under debugger, or a crash, if run outside of one.) So I just don't get the whole idea of the above if statement.
02CD1B7F mov dword ptr [esi],edi
513: dwNumBytes = WaitForRX(*psThreadData, sNotifyOverlapData);
02CD1B81 lea eax,[sNotifyOverlapData]
02CD1B84 push eax
02CD1B85 push esi
The esi here contains psThreadData address, and is pushed onto the stack, and later on WaitForRX will pop it off.
02CD1B86 call WaitForRX (02cd1bbb)
02CD1B8B pop ecx
It did NOT hit the breakpoint set at lines 511 / 512, so the pointer was still valid when it went into the call.
Like I said above, if it did, then you would face an exception. You're sure you have not made any such mistakes in these hot areas of the code we're discussing?
Here's WaitForRX(), with the breakpoint I added and it triggered:
DWORD WaitForRX(COMMS_RX_THREAD_DATA_S& rsThreadData, OVERLAPPED& rsNotifyOverlapData)
{
BOOL bDone ;
COMSTAT sStatus ;
DWORD dwEvent, dwError, dwDummy, dwNumBytes ;
dwNumBytes = 0 ; // Until we have definitely been notified of something
// being received.
// JDEBUG
if ( (DWORD)&rsThreadData == 0x00000001)
dwDummy = 0 ; <== Hit breakpoint here
if (!::WaitCommEvent(rsThreadData.hPortHandle, &dwEvent,
&rsNotifyOverlapData) )
{
Is this all the code without getting any part of it trimmed off? If this is all of it, then you might have caught a compiler bug!
A likely reason for this symptom is stack corruption, which is of course not likely if you have cited the complete code, because other than declaring some variables (which translates to shifting off the esp register) you are not doing anything which can overflow/corrupt some part of the stack. Anyway, one way of testing it is allocating a big char array (say, 1KB) at the beginning of WaitForRX, and seeing if the problem occurs again. Are you having deep recursive calles? IOW, how deep is the stack trace when the breakpoint hits?
If none of the above makes sense, please post the full code of both WaitForRX and its caller, together with the compiler generated asm code so that we can have a look.
As you can clearly see, it got corrupted on entry to the call! Bearing in mind it will have gone through this call hundreds of times successfully before it (apparently) suddenly fails...
This is why I suspect you've caught a compiler bug, provided that you have posted the code without any serious trim-offs. :-)
I can confirm that the only other place the structure is referenced by the pointer passed to the comms thread is in ReceiveBytes(), which doesn't get called until AFTER WaitForRX(), and there are checks to make sure the pointer isn't going wrong after that - and it is not. The original structure is not being used beyond when the thread is created and its address is initially passed, and it is not going out of scope.
How is this possible?
Magic. Black Magic!
OK I understand that you might not be in a position to tolerate my unbearable sense of humor, because at your situation I'd have been pulling my hair out, but please bear with me. I'm just making the big test I'm gonna have in two days easier on myself...
And don't worry, we'll track it down.
:-)
---------
Ehsan Akhgari
www.farda-tech.com
List Owner: [email protected]
[Email: [EMAIL PROTECTED]]
[WWW: http://www.beginthread.com/Ehsan
]
| They have something of which they are proud.
What do they call it, that which makes them proud? Culture, they call it;
it distinguishes them from the goatherds. -Thus Spoke Zarathustra, F. W. Nietzsche |
_______________________________________________ msvc mailing list [email protected] See http://beginthread.com/mailman/listinfo/msvc_beginthread.com for subscription changes, and list archive.
