Il 16/02/2016 10:04, Michael Schnell ha scritto:
a (potential) bug (in "Glib2" whatever this exactly means)
Glib2 means version 2 of GTK Glib, which is used by Qt (and by GTK) to
implement the main event loop.
libglib-2.0.so.0
The full picture (from stack trace) is as follows:
1. The main
Il 16/02/2016 10:04, Michael Schnell ha scritto:
Anyway, IMHO it's not a good idea to fight a (potential) bug (in
"Glib2" whatever this exactly means) by implementing a completely
queer behavior in Application.ProcessMessage.
I fully agree with you. Seeing a unexpected recursion, I had
On 02/15/2016 07:23 PM, Giuliano Colla wrote:
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
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
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
Il 12/02/2016 15:35, Michael Schnell ha scritto:
On 02/12/2016 03:17 PM, Mattias Gaertner wrote:
IMHO, Michael, you should not redefine words. It confuses people.
Reentrant means it can be called again, while it is still running. It
does not need to be thread-safe.
Sorry that was not me.
On 02/12/2016 03:17 PM, Mattias Gaertner wrote:
IMHO, Michael, you should not redefine words. It confuses people.
Reentrant means it can be called again, while it is still running. It
does not need to be thread-safe.
Sorry that was not me. The subject here is " thread save " ,so I
On 02/10/2016 10:12 PM, C Western wrote:
My understanding is Application.ProcessMessages has to be reentrant ...
As calling Application.ProcessMessages is only allowed from the main
thread it does not need to be reentrant = thread-save.
Of course it can be called recursively and it hence
On Fri, 12 Feb 2016 14:53:29 +0100
Michael Schnell wrote:
> On 02/10/2016 10:12 PM, C Western wrote:
> >
> > My understanding is Application.ProcessMessages has to be reentrant ...
>
> As calling Application.ProcessMessages is only allowed from the main
> thread it does not
Il 10/02/2016 21:13, Giuliano Colla ha scritto:
I don't believe that there's an easy way to protect
Application.ProcessMessages from recursion unless someone is willing
to debug and patch Glib (which is used not only by Qt, but also from
GTK, if I'm not wrong).
A snippet from gmain.c:
#if 0
Il 10/02/2016 13:48, zeljko ha scritto:
I believe
that Application.ProcessMessages should protect itself too, avoiding to
handle more than once the same message.
But where ? In LCL or per widgetset ?
I skimmed through the backtrace. It would appear that the recursion
originates in
On 10/02/16 20:13, Giuliano Colla wrote:
Il 10/02/2016 13:48, zeljko ha scritto:
I believe
that Application.ProcessMessages should protect itself too, avoiding to
handle more than once the same message.
But where ? In LCL or per widgetset ?
I skimmed through the backtrace. It would appear
Il 10/02/2016 00:18, Denis Kozlov ha scritto:
Is your LM_ERROR larger than LM_USER?
Yes :
const
LM_ANSWER= LM_USER + 100;
LM_MESSAGE = LM_USER + 101;
LM_ERROR = LM_USER + 102;
Giuliano
--
___
Lazarus mailing list
Il 10/02/2016 00:22, Denis Kozlov ha scritto:
You create a recursive scenario yourself by calling
Application.ProcessMessages inside of ShowError inside of HandleError
- which is the message handling procedure itself, which is triggered
by Application.ProcessMessages.
That's what I had
Il 10/02/2016 08:44, zeljko ha scritto:
1.Your ErrList access does not look thread safe.
It's a poor man's thread safe queue, implemented as a ring buffer, with
two indexes, ErrGet and ErrPut. It's fully safe, provided the buffer is
guaranteed not to overflow, and that ErrPut is updated only
On 02/10/2016 11:19 AM, Giuliano Colla wrote:
This I believe to be the problem. From the observations from Denis I
realized that my code isn't protected against recursion, but I believe
that Application.ProcessMessages should protect itself too, avoiding to
handle more than once the same
Il 10/02/2016 12:31, zeljko ha scritto:
On 02/10/2016 11:19 AM, Giuliano Colla wrote:
This I believe to be the problem. From the observations from Denis I
realized that my code isn't protected against recursion, but I believe
that Application.ProcessMessages should protect itself too, avoiding
On 02/10/2016 12:48 PM, Giuliano Colla wrote:
Il 10/02/2016 12:31, zeljko ha scritto:
On 02/10/2016 11:19 AM, Giuliano Colla wrote:
This I believe to be the problem. From the observations from Denis I
realized that my code isn't protected against recursion, but I believe
that
Il 10/02/2016 22:12, C Western ha scritto:
My understanding is Application.ProcessMessages has to be reentrant
for the clipboard to work, at least under X, as clipboard content is
retrieved by receiving messages. See
http://bugs.freepascal.org/view.php?id=26242 for a (fixed) bug that
showed
On 09/02/2016 22:37, Giuliano Colla wrote:
PostMessage(Form1.Handle,LM_ERROR,Integer(ErrPut),0);
Is your LM_ERROR larger than LM_USER?
PostMessage is thread safe.
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
You create a recursive scenario yourself by calling
Application.ProcessMessages inside of ShowError inside of HandleError -
which is the message handling procedure itself, which is triggered by
Application.ProcessMessages.
--
___
Lazarus mailing
On 02/09/2016 11:37 PM, Giuliano Colla wrote:
Hi Lazarus guru's,
I have stumbled into a problem with a Lazarus application. At random
times, from 5 minutes to several hours, it crashes suddenly, and silently.
The only way to get a clue has been to run it with gdb.
It turns out that the crash
22 matches
Mail list logo