🔒 Locked

Message Posting...

Started by bose Nov 24, 2001 at 4:53 PM 2 replies 300+ views

Original Post

Nov 24, 2001 at 4:53 PM

I am having a problem that I can''t explain or pinpoint. Basicly what I have going on is (MFC) a main dialog containing a client socket class within it. When the client socket connects to the server, it calls the OnConnect callback function. Now since I want the main dialog to know that the user has connected to the server, I am doing a pMainDlg->PostMessage to post a custom "WM_USERCONNECT" message to the main dialog. The main dialog message map contains: "ON_MESSAGE(WM_USERCONNECT, OnUserConnect)". The OnUserConnect function is an afx_void callback that prints the results of the connection (failure or success) to the console. Problem is:: When I first connect and the message is posted, it works. The 2nd time I connect I get an illegal error: access violation. I tested things a lot and I found that the error occours no matter what other callback function I use to handle the WM_USERCONNECT message, which means the problem does not lie within the callback. Another interesting thing is if I change PostMessage to SendMessage, the error happens on the first connection instead of the 2nd! Can anyone give me any insight i may be missing with the message posting thing? Thanks!

S1CA

Nov 24, 2001 at 5:30 PM

PostMesage posts into the message queue for the target, so other messages may be processed before your custom message gets recieved. PostMessage enters the message into the queue and returns immediately. The processing of the message by the target happens "some time in the future".

SendMessage calls the targets window procedure directly. Also it''s blocking in nature so that the thread which calls SendMessage blocks until the target has recieved and finished processing the message.

It sounds like you could have some sort of syncronisation issues somewhere, possibly you''re expecting messages in a certain order and/or expecting an earlier message to fill in some crucial data (messages have different priorities and there are multiple queues so messages posted sequentially aren''t necessarily recieved sequentially).

How about running the application in the debugger (F5) and seeing what the access violation is related to in your code.

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

bose

Nov 24, 2001 at 5:57 PM

That''s why I can''t figure it out, the error even occours of I have NO CODE inside of the callback function, so I know its nothing relying on anything else. And also I can''t reallt debug it because it only happens in Release mode, nothing wrong in debug! So I am not able to debug the release disassembly myself =(

What does the debug do different that could cause it to work and the release to have an access violation?

S1CA

Nov 24, 2001 at 8:48 PM

Debug builds are more tolerant to overwriting array bounds, trashing memory etc.

Release builds are optimised - sometimes if the compiler didn''t quite understand your intentions it''ll mis-generate code. An example would be trying synchronise between two threads manually - if the compiler wasn''t aware that the variable could be changed by external influences it often would totally remove all references to it when optimising.

Other more obvious things include code inside asserts actually being used for more than just checking.

Tracking release build crashes is a particular pain. The best solution is a process of elimination:

1. change the project settings for the release build so that the executable code contains debug information. The idea is to leave optimisations on so that when the crash happens you have an idea of where the crash is happening. The exact code line the debugger jumps to isn''t the one where the crash is (due to code re-organisation by the optimiser) but it''ll give you a rough idea of where the problem is (and the call stack).

2. try turning off optimisations but still making a release build. If the code works, it''s likely you''ve confused the compiler (may need a few "volatile" type specifiers). If the code still doesn''t work without optimisations, the problem is likely either code inside asserts/traces being more than just checks or something such as a memory trash (the release memory manager isn''t as tolerant).

3. start stripping the code in a methodical way until the problem stops happening. Refine and isolate.

--
Simon O''''Connor
Creative Asylum Ltd
www.creative-asylum.com

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.