SendMessage (in secondary thread) freezes application GUI thread?

[skyapie]

Hi,

Has anyone ever come across the same problem and found a solution to the
following?

I have 1 background thread that periodically calls "SendMessage". The
SendMessage sends a message to my main thread (which also handles the GUI),
saying "start processing!" The main thread then starts processing, and
returns to the secondary thread when it has completed the processing it needs
to do and updated the GUI.

This works fine most of the time, but randomly the GUI on my application
will freeze (I can tell because there's a clock on the screen that suddenly
just disappears... and this clock changes the time it displays by doing a
time(&currentTime), and updating the display on every OnDraw function call.
(Received when WM_PAINT gets processed).

The odd thing is, the application un-freeze (come back to life) after 1/2
hour to 1 hour... And all my logging statements always stop at the same point
when my application freezes. I log a statement before SendMessage, and at the
point where the message handling function gets entered. My log shows that the
SendMessage statement gets executed, but the message handling function in the
active view doesn't get entered.

Can anyone help please?? I have no clue how to debug into SendMessage, let
alone reproduce this consistently. The freezing seems to happen randomly at
the same point in the code. (IE: it works most of the time.... )

Much appreciated
skyapie

[skyapie]

Asking this question in a simpler way,

What could cause SendMessage to get stuck, causing the receipient hWnd to
not get it's message?

Thanks
skyapie

"skyapie" wrote:

> Hi,
>
> Has anyone ever come across the same problem and found a solution to the
> following?
>
> I have 1 background thread that periodically calls "SendMessage". The
> SendMessage sends a message to my main thread (which also handles the GUI),
> saying "start processing!" The main thread then starts processing, and
> returns to the secondary thread when it has completed the processing it needs
> to do and updated the GUI.
>
> This works fine most of the time, but randomly the GUI on my application
> will freeze (I can tell because there's a clock on the screen that suddenly
> just disappears... and this clock changes the time it displays by doing a

> time(¤tTime), and updating the display on every OnDraw function call.

[Paul G. Tobey [eMVP]]

SendMessage blocks until the window that you've sent the message to is done
processing it (that's why PostMessage exists). I would guess that you have
a deadlock there.

Thread A calls SendMessage while holding an exclusive lock on something.
This might be a mutex, a spin lock, almost any object designed to prevent a
second thread from accessing some resource.

Thread B calls GetMessage() and begins processing it, but, because there's a
lock on the object, it goes into a wait state until the lock is released.

Obviously, the lock is never going to be released, since SendMessage doesn't
return until the message processing is complete. It's possible that the
'lock' is something which is automatically released by the OS after some
period of time or there might be a long time-out on the wait.

Paul T.

"skyapie" <sky...@discussions.microsoft.com> wrote in message
news:9416563C-37F0-46DC...@microsoft.com...

> Asking this question in a simpler way,
>
> What could cause SendMessage to get stuck, causing the receipient hWnd to
> not get it's message?
>
> Thanks
> skyapie
>
> "skyapie" wrote:
>
>> Hi,
>>
>> Has anyone ever come across the same problem and found a solution to the
>> following?
>>
>> I have 1 background thread that periodically calls "SendMessage". The
>> SendMessage sends a message to my main thread (which also handles the
>> GUI),
>> saying "start processing!" The main thread then starts processing, and
>> returns to the secondary thread when it has completed the processing it
>> needs
>> to do and updated the GUI.
>>
>> This works fine most of the time, but randomly the GUI on my application
>> will freeze (I can tell because there's a clock on the screen that
>> suddenly
>> just disappears... and this clock changes the time it displays by doing a

>> time(川Time), and updating the display on every OnDraw function call.

[skyapie]

Hi Paul,

Thanks for the reply, but I can't see how that could happen in my
application...

Thread A sends the message, and Thread B receives it via:

ON_MESSAGE(THE_MESSAGE, theFunctionThatProcessesTheMessage)

I have a logging statement just before sending the message in thread A, and
another logging statment at the very start of
"theFunctionThatProcessesTheMessage". This log statement never gets logged
(when the freeze happens)... which is why I realised thread B was not even
starting to process the message.

The next point is... I've replaced SendMessage with PostMessage and
SendNotifyMessage, but everything's identical... the application will work
for awhile... and randomly freeze for 1/2 hr to 1 hr...

I can see that there's a resource lock somewhere, could you give me some
recommendations on how to go about debugging this?
(Could the resource lock be on an mfc component somewhere? which is why my
GUI is freezing?)

thanks,
skyapie

> >> time(¤tTime), and updating the display on every OnDraw function call.

[skyapie]

Do I need to use GetMessage?
Will ON_MESSAGE(x, y) remove the message from the message queue as well?

"Paul G. Tobey [eMVP]" wrote:

> >> time(¤tTime), and updating the display on every OnDraw function call.

[Paul G. Tobey [eMVP]]

That doesn't sound like the messaging is the problem, then. I can't advise
you what to do, but, if it were me, I'd make really sure that I wasn't
damaging the heap, accessing a data buffer which didn't exist, possibly
because of the threading architecture of my application, etc. You can run
Entrek's tools on your application to check for buffer overrun/underrun,
etc. That's a good starting point.

Certainly MFC could be at fault, but I don't recall ever hearing about this
before. I dislike MFC, as it's barely a C++ wrapper around the API, not a
real application framework, so I don't use it much. I'd concentrate on your
own code, as I think that it's most likely a bug there, although it might be
something that you're doing that's stepping on MFC's toes...

Paul T.

"skyapie" <sky...@discussions.microsoft.com> wrote in message

news:72BA9038-EC39-4AD4...@microsoft.com...

>> >> time(川Time), and updating the display on every OnDraw function call.

[Paul G. Tobey [eMVP]]

It might help to understand how a Win32 application works. Since MFC is
just a class library, it *is* calling GetMessage(). It's just doing it for
you and you aren't coding it explicitly.

Paul T.

"skyapie" <sky...@discussions.microsoft.com> wrote in message

news:CB036DCB-6925-4AA9...@microsoft.com...

>> >> time(川Time), and updating the display on every OnDraw function call.

[Michael J. Salamone]

I do think it's a deadlock. Just set a break on the call to SendMessage.
When you get there, get the callstack from the UI thread. Where's it at?
If it's not calling GetMessage or some variant - i.e. not in a message
pump - that's the problem and hopefully seeing where the thread is will clue
you in to the solution.

A little more detail on how SendMessage works across threads (high level):
the calling thread, under the covers, posts the message to the UI thread and
then blocks until the UI thread processes the message (by running a message
pump e.g. GetMessage/DispatchMessage) and is completed (returns from the
WndProc). Once completed, the calling thread is unblocked. If the UI
thread is not running a message pump (as Paul pointed out, MFC provides the
message pump), then the calling thread is blocked. Even though MFC provides
the message pump, it's possible your UI thread is doing something (or more
likely it's blocked) such that it didn't return to MFC so it can run its
message pump.

--
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:OrNsJZBB...@TK2MSFTNGP03.phx.gbl...

[Paul G. Tobey [eMVP]]

I bet you're right, Michael. I hadn't thought of that scenario.

Paul T.

"Michael J. Salamone" <mikesa#at#entrek#dot#com> wrote in message
news:OtE77xBB...@TK2MSFTNGP02.phx.gbl...

[Doug Forster]

Just on a completely different tack, you *are* aware that you should not
pass MFC objects across thread boundaries? Doing this can lead to all sorts
of problems, though SendMessage itself is a very thin wrapper so should be
ok.

Cheers
Doug Forster

[skyapie]

ok thanks for that, I'll try it out.... =)

the hard bit is that the problem only reproduces itself once in a very long
while... sometimes after 1000 mesages, maybe even more... (it only occurs
once within 1 hour to 5 hours) plus I've never been able to reproduce the
problem while the application is running in the debugger...

If the UI was doing something and not returning to MFC, then the last log
statement I see should not be the log before SendMessage, but the first line
in my UI where it receives the message.. because it meant that the UI
actually received the message... wouldn't it?

I'll try stepping into the SendMessage and check out the callstack though,
thanks for that suggestion :) Please let me know if you think of any others.

"Michael J. Salamone" wrote:

> >>> >> time(¤tTime), and updating the display on every OnDraw function call.

[Michael J. Salamone]

Best thing is probably a code review. Review your usage of critical
sections, mutexes, etc. Does the UI thread ever do a Wait? Any chance it
doesn't come out of that wait (i.e. what circumstances would cause it to
wait forever)?

You could try setting a flag just before waiting and then clearing after the
wait. Then, in the non-UI thread, check the flag. If the flag is set,
throw up a MessageBox. Then attach the debugger to the program and get some
stack traces.

--
Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com

"skyapie" <sky...@discussions.microsoft.com> wrote in message

news:C66659A1-D685-43E2...@microsoft.com...

>> >>> >> time(川Time), and updating the display on every OnDraw function

[skyapie]

Hi guys, me again... =)

I have a question... what happens if there are 3 threads, and 2 threads
simultaneously do a "SendMessage" to the third one?

Plus, what if Thread A is actually sending a message to the UI thread,
saying that it has received a Power Broadcast message, and that the system
was about to go into suspend mode... and the UI thread was in the middle of
processing Thread B's message?

Thanks...

"Michael J. Salamone" wrote:

> >>> >> time(¤tTime), and updating the display on every OnDraw function call.

[Paul G. Tobey [eMVP]]

One or the other will win and that message will end up in the queue first,
will, presumably, be handled first by the third thread, and that application
will be released first. Then the next message will be at the top of the
queue and, again, the third thread will process that.

What's the question? If the system is about to go into suspend mode, it
will probably suspend before the about-to-suspend message gets to the UI
thread. When the device resumes, that message will still be there...

Paul T.

"skyapie" <sky...@discussions.microsoft.com> wrote in message

news:BB5466B6-F02A-4F1E...@microsoft.com...

>> >>> >> time(川Time), and updating the display on every OnDraw function

[skyapie]

Thanks for that Paul.

This is what I actually see in my log:

Thread B: Before Sending Message
UI: Received Message, processing now
UI: Finished processing, returning
Thread B: Returned from Sending Message
.
. (The above gets repeated a random amount of times...)
.
Thread B: Before Sending Message
****************************** And this is the point the application GUI
hangs at.

Putitng together what you and Michael have taught me, my guess is that the
main application is deadlocked, as to why it's deadlocked, I was
investigation the possibility of another message being sent at the same time,
causing the UI to freeze. But with what you've just replied, it seems not
possible... each message will be processed in turn. What's probably happening
is that the message is getting sent, but the UI thread is processing some
other message and deadlocking on that message... and the OS is un-deadlocking
after half an hour.

Now I just got to figure out which message getting processed is the one
causing the deadlock.... (any clues as to how to do this?)

Thanks :)

> >> >>> >> time(¤tTime), and updating the display on every OnDraw function

[Michael J. Salamone]

Did you try the suggestion I made earlier?

Does the UI thread ever do a Wait (or other blocking call)? Any

chance it doesn't come out of that wait (i.e. what circumstances
would cause it to wait forever)?

You could try setting a flag just before waiting and then clearing
after the
wait. Then, in the non-UI thread, check the flag. If the flag is
set,
throw up a MessageBox. Then attach the debugger to the program and
get some stack traces.

--

Michael Salamone [eMVP]
Entrek Software, Inc.
www.entrek.com

"skyapie" <sky...@discussions.microsoft.com> wrote in message

news:23E99DE6-7FDA-4A69...@microsoft.com...
> Thanks for that Paul.

[skyapie]

Yupyup I tried it... I even commented out all the places I could find Waits
and semaphores... and just disabled those functions that had it.... the
problem wasn't there... it was still freezing... I still appreciate your help
though, I've learnt a bit at least :)

Then I put logging statements in the OnDraw function, and found out it was
freezing in there. I had a call to "GetSystemPowerStatusEx2" to get the
battery power every time the screen had to be re-drawn, and it would often
hang in there. Once I removed the call to display the percentage of battery
power left, the application stopped hanging...

I tried reducing the frequency of the calls, to once per minute instead of
once every OnDraw, but that still caused the application to freeze.... I was
just thinking of putting it in a different thread so even if that thread
died.... the main thread wouldn't be affected. (but that kind of hides the
problem even more...)

It was kind of weird that it was dying there.... but at least the source of
the problem's found :) I can now look for a solution :)