Il 15/02/2016 11:54, Michael Schnell ha scritto:
On 02/13/2016 12:27 PM, Giuliano Colla wrote:
At least under Qt widgetset, it may happen that calling
Application.ProcessMessages from within a Message Handler will cause
the same message which was being processed to be processed again, the
handler called again and Application.ProcessMessages being called
again, thus originating an endless loop and a consequent stack overflow.
When calling Application.ProcessMessages from within a Message Handler
the *next* event in the event queue should be handled. If
*the*event*already*being*handled* pops up again, that would be a bug.
But of course "the same" message might have pushed by some thread and
also needs handling. Here the same handler might be called
recursively. This of course does need additional stack space, but not
infinitely .
I'm positively sure that the message being handled is *the same* for a
number of reasons.
It is identified by an "errorstring" which from the stack dump is always
the same.
It cannot be sent more than once, because where it originates it waits
for a user error reset, before sending the next. Moreover, the error
messages originate in a real-time part, which has a pool of just 40
messages, therefore it can't possibly send 1722 messages.
The same code has been field tested in hundreds of application which
have been running for many years (since 2005), with the only difference
that the messages were handled in the OnIdle Handler, waking up the main
thread periodically with a timer event, instead of waking up the main
thread with a PostMessage.
The result is to make Application.ProcessMessage not 100% reentrant,
because of a Glib2 bug.
Would you suggest not to handle "the same" event ? How should you
detect that its the event already in the works or the next occurrence ?
In the case I've stumbled into, when next message eventually comes
(after 1722 iterations over the previous one) the program crashes for a
SEGFAULT, most likely generated by a stack overflow.
Giuliano
--
_______________________________________________
Lazarus mailing list
[email protected]
http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
