https://bugs.kde.org/show_bug.cgi?id=501713
zephyrus00jp <ishik...@yk.rim.or.jp> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|RESOLVED |REOPENED
Resolution|NOT A BUG |---
--- Comment #5 from zephyrus00jp <ishik...@yk.rim.or.jp> ---
(In reply to Paul Floyd from comment #4)
> So not an issue with memcheck.
I am afraid that I have o disagree here.
There is an issue of memcheck here, which I have not seen before.
memcheck changes the behavior of the program here.
In normal circumstances, |rv| is set properly in the lambda/function that is
executed in another thread.
(That lambda/function invocation is supposed to be waited.)
Here, I found that somehow the control flow is no longer which is supposed to
happen (the execution of lambda/function via DispatchToThread() is waited until
completion) during the execution of thunderbird.
I don't know the details, but here is the first case I have seen memcheck
changed the behavior of thunderbird which resulted in logical error, and
reported.
As I noted in comment 43 (which may not have been clear)), under normal
circumstances, |rv| is set correctly before returned.
HOWEVER, UNDER VALGRIND/MEMCHECK
> NS_NewRunnableFunction("nsImapProtocol::IsTransportAlive",
> GetIsAlive)); <--- calling thread does not stop here to wait for
lambda
(GetIsAlive), and proceeds.
but UNDER NORMAL RUN WITHOUT VALGRIND, the calling thread STOPS HERE TO WAIT
FOR lambda (GetIsAlive).
Sorry, it was not clear.
But since memcheck somehow changes the control flow despite thread context
switch and
the wait introduced by monitor/lock, the value returned is uninitialized.
See the synchronization code at
https://searchfox.org/mozilla-central/source/xpcom/threads/SyncRunnable.h#71
This thread code was written in 2014 and I assume it has worked well for
Firefox and Thunderbird for more than a decade.
However, the particular instance of the DispatchToThread() call was introduced
in 2023. So this particular line of code may have uncovered an issue with
memcheck and the primitives of thunderbird mail client. However, plase note
there are tons similar call patterns in Firefox created more than dozen years
ago or so.
See the calls to DispathToThread() in mozilla code base. There are several
dozens such places.
https://searchfox.org/mozilla-central/search?q=DispatchToThread&path=&case=false®exp=false
I assume they have worked under valgrind because there were people who ran
firefox under valgrind to
find errors.
So I wonder what has changed in the last couple of years when I could not run
thunderbird under valgrind due to the change of framework for its test suite.
(From mozimill to mochitest).
Compiler's generated code? I am using GCC-14 for now.
Binary utilities?
Both valgrind 3.24.0 and valgrind-3.2.5.0GIT ( I compiled locally) showed the
symptom.
valgrind 3.23 was too old to run thunderbird code of today since there are some
syscalls which were not handled by valgrind 3.23.
I initially thought of inserting my own sync primitive, but then I realized
that thunderbird/firefox has already implemented it already.
https://searchfox.org/mozilla-central/source/xpcom/threads/SyncRunnable.h#71
So I am puzzled what I can to make valgrind and thunderbird run together by
sticking to the thread synchronization behavior observed under normal run.
--
You are receiving this mail because:
You are watching all bug changes.
