Thread & Message pb?

[Ori 0]

Hi, I have a strange bug in something I'm working on: The main program gets a message every few seconds from a different thread that does ::PostMessage(MY_MSG, (WPARAM)sString, LPARAM(nNumber); The function that handles this message in the main thread, gets the sString address correctly 99% of the times except from a unique scenario that causes the sString adderss to be cut in half - I'm getting only the LOWORD value of the address. For example: When running correctly, (WPARAM)sString is at 0x0172F6B8 When the bug happens it's only F6B8. The bug happens when you cause the message to be posted twice with little time in between. Any clues? I'm a bit helpless here... Ori

[Ori 0]

I also forgot to mention one more important thing: This only happens on Win9x\ME and not on the NT series.

[Erik Funkenbusch]

You're probably losing part of the message due to the 16 bit nature of the Win9x subsystems. They're not completly 32 bit, and if your message happens to pass through a 16 bit subsystem, it will get truncated to 16 bit. How are you defining MY_MSG? It should be WM_APP + some unique number (not WM_USER).

[Ori 0]

The MSG is defined as WM_APP + 2. There is no other equivalent MSG value that might collide with this. I have thought of the option of 16 BIT trancation, but if that is the case, isn't it supposed to happen more often? It only happens on a very specific scenario, and not 100% reconstructable (Timing?). Is there any solution for this? specifing the use of 32 bit addresses?

[Erik Funkenbusch]

The only thing I can suggest is to use a different way of transfering your data. Perhaps a global variable or shared memory segment or even a stack.

[Mark Jones]

Hi Ori, I agree with the other poster who mentions that your user message definitions should start at WM_APP, rather than WM_USER. I actually start at WM_APP+0x100 just to be sure of no clash. However, I do not think this is the problem, and I don't think we can put the problem down to differences between win 9x and win nt. The problem you described can be caused if the destruction of the sString object is not *guaranteed* to be determined by the code receiving MY_MSG in the main program. For example, allocating sString on the stack in a worker thread would be bad news. This is because you don't know if sString has been destructed when the main program gets round to pumping its message queue sufficiently to get hold of MY_MSG. On some program runs it might work - others it won't, such is the realm of multi-threaded programming. This can be avoided by using SendMessage, which will block your worker thread until the main program has processed MY_MSG, thus guaranteeing sString points to valid memory for the duration of execution of the MY_MSG handler. I'll give an example of how I'd do this using PostMessage. If I've got the wrong end of the stick - sorry - please post me and I'll try again - this is my first post to CodeProject. void CWorkerThread::SomeFunction() { CString* pstrText=new CString(_T("Test")); int iSomeNumber=0; // Transfer ownership of the memory pointed to by // pstrText to the receiver of MY_MSG, ie he who // processes MY_MSG must do 'delete pstrText'. ::PostMessage(MY_MSG, (WPARAM)pstrText, (LPARAM)iSomeNumber); // This thread does not control the lifetime of the // memory pointer to by pstrText now. So... // we mustn't delete pstrText here // we shouldn't dereference pstrText here // and probably should just deny all knowledge // that *pstrText ever existed... nullify pstrText! pstrText=NULL; } LRESULT CMainProgram::OnMyMsg(WPARAM wParam, LPARAM lParam) { // Document the fact that the memory pointed to by // pstrText is now 'owned' by this function. CString* pstrText=(CString*)wParam; int iSomeNumber=(int)lParam; // do some stuff with pstrText and iSomeNumber // .... // because we own pstrText, we must delete it delete pstrText; pstrText=NULL; // just for safety return 0; } Does this help? Mark