dia_rich
asked on
mfc vc++ dialog app stops updating screen.
Simple Dialog Application, Screen updates stop and or don't display correctly.
Multi-threaded to communicate via connected sockets, serial ports, pipes, events, user created messages.
Writes to a text log file (this keeps happening when the screen updates stop).
Works just great for 55 minutes, then the screen updates stop.
A list control in the dialog seems to keep updating as required, but
a multi-line edit control (write only, duplicate of the text log) stops, as well as
a number of static text controls, (one is a digital clock) both text and background color updates.
A child dialog can be brought up but doesn't display correctly.
No memory leaks are reported when the app is halted in the debugger (VS 2005 standard).
I must have something really foobar`ed.
Any thoughts as to how to find out what?
Multi-threaded to communicate via connected sockets, serial ports, pipes, events, user created messages.
Writes to a text log file (this keeps happening when the screen updates stop).
Works just great for 55 minutes, then the screen updates stop.
A list control in the dialog seems to keep updating as required, but
a multi-line edit control (write only, duplicate of the text log) stops, as well as
a number of static text controls, (one is a digital clock) both text and background color updates.
A child dialog can be brought up but doesn't display correctly.
No memory leaks are reported when the app is halted in the debugger (VS 2005 standard).
I must have something really foobar`ed.
Any thoughts as to how to find out what?
Sounds like it could be a resource leak.
You don't get warnings about these from the IDE when your app finishes :-(
Basically windows uses handles to identify things. There is a fixed maximum number of handles available to the operating system - when you use one then don't give it back, then another.... until the op system freezes typically with display problems first.
You don't get warnings about these from the IDE when your app finishes :-(
Basically windows uses handles to identify things. There is a fixed maximum number of handles available to the operating system - when you use one then don't give it back, then another.... until the op system freezes typically with display problems first.
ASKER
Andy
I believe that your suggestion is the most likely cause of my issue.
How does one programmatically ensure that used handles are released?
I believe that your suggestion is the most likely cause of my issue.
How does one programmatically ensure that used handles are released?
It is beginning of typical elimination process that I can only describe in abstract since I have no idea of what application does or what the circumstances are.
Option 1, if you have any goof performance monitor application, use that on the app
Option 2: To rapidly locate the problem, I'd replace the client of application by a stub code (dummy) and then introduce resources back into the pool one by one until app breaks again.
Also, there are tricks such as artificially reducing available memory so that error would crop up sooner These utilities typically ship with Studio doubt you as a person have patience to wait 55 minutes. OR
you can write your own memory gobbler.
Option 1, if you have any goof performance monitor application, use that on the app
Option 2: To rapidly locate the problem, I'd replace the client of application by a stub code (dummy) and then introduce resources back into the pool one by one until app breaks again.
Also, there are tricks such as artificially reducing available memory so that error would crop up sooner These utilities typically ship with Studio doubt you as a person have patience to wait 55 minutes. OR
you can write your own memory gobbler.
Releasing handles - no easy method that I know of.
For example when a Font is selected into a windows element at some point it should be de-selected to release it. (same for pens, brushes....)
For example when a Font is selected into a windows element at some point it should be de-selected to release it. (same for pens, brushes....)
ASKER
If handles were being consumed wouldn't that be shown in the task manager (I should have mentioned that this is on a XP box.)? Because they aren't.
Updates that stop in a multithreaded application are frequently caused by cross-thread manipulation of a window.
For example, if you use SetWindowText() on the edit control, but call it from a worker thread, then that would be a cross-thread manipulation of a window, and should be avoided. Basically, a rule of thumb is that you should not manipulate a window directly from any thread other than the thread that created the window.
Indirect manipulations are fine. For example, one common resolution of the above is for the worker thread to PostMessage a user-defined message to the window's thread, wherein the the user-defined message contains enough information to locate the text that should be displayed. Then, in the handler for the user-defined message, which will be executed in the thread context of the window, the text is located and SetWindwoText() is called from there.
For example, if you use SetWindowText() on the edit control, but call it from a worker thread, then that would be a cross-thread manipulation of a window, and should be avoided. Basically, a rule of thumb is that you should not manipulate a window directly from any thread other than the thread that created the window.
Indirect manipulations are fine. For example, one common resolution of the above is for the worker thread to PostMessage a user-defined message to the window's thread, wherein the the user-defined message contains enough information to locate the text that should be displayed. Then, in the handler for the user-defined message, which will be executed in the thread context of the window, the text is located and SetWindwoText() is called from there.
ASKER
The worker threads put data into pipes and then set Messages which get processed.
I have a timer message processor which sets some the static text based on global variables and
the OnCtlColor to set background color for the text.
Could the Message Pump be stalling?
I have a timer message processor which sets some the static text based on global variables and
the OnCtlColor to set background color for the text.
Could the Message Pump be stalling?
Resource handles.
When your app starts having problems do other apps also start having display problems, especially ones you then start.
eg.
Run your app until the display problems start. Now without closing this app open winword, browser... Do they work properly? If yes then it probably is not related to resource handles. However if they also behave oddly in display then it could be due to your consuming handles and not releasing them.
When your app starts having problems do other apps also start having display problems, especially ones you then start.
eg.
Run your app until the display problems start. Now without closing this app open winword, browser... Do they work properly? If yes then it probably is not related to resource handles. However if they also behave oddly in display then it could be due to your consuming handles and not releasing them.
ASKER
Other apps seem to function & display properly.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Hmmm - it was not releasing resource handles then.
ASKER
I would have thought the same thing except when I watched the "handles" with task manager nothing
much was changing.
I had to use processes tab and then the view menu and then select handles and GIDs
which added that column to the task manager. "handles" were constant.
GIDS (or rather GD GIDs) were counting up and up. . .
GIDs are special case of "handles". Had to look in obscure places to track down what to look for and
then guess as to what object was being left on the heap. . .
Nothing I remember reading about for mfc objects warned about these special handles.
much was changing.
I had to use processes tab and then the view menu and then select handles and GIDs
which added that column to the task manager. "handles" were constant.
GIDS (or rather GD GIDs) were counting up and up. . .
GIDs are special case of "handles". Had to look in obscure places to track down what to look for and
then guess as to what object was being left on the heap. . .
Nothing I remember reading about for mfc objects warned about these special handles.
I just know them as handles - in the early nineties I tracked a problem down which involved a third party app chewing up (resource) handles (on 16 bit windows where there were many less available) which caused the system to freeze after 30-40 minutes, first with things not drawing correctly then gradually grinding to a halt.
Maybe some terminology has changed.
Maybe some terminology has changed.
Probably, there is a problem with a critical section a mutex. Check all places where you enter to a critical section or lock the mutex.