[Lazarus] Lazarus application crash. Is PostMessage thread safe?

[Giuliano Colla]

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