https://bugs.kde.org/show_bug.cgi?id=501713
Bug ID: 501713
Summary: Thread behavior is not expected when I run thunderbird
client under valgrind. (Frist time seen.)
Classification: Developer tools
Product: valgrind
Version: 3.25 GIT
Platform: PCLinuxOS
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: memcheck
Assignee: jsew...@acm.org
Reporter: ishik...@yk.rim.or.jp
Target Milestone: ---
SUMMARY
I ran thunderbird mail client under valgrind.
There is a test suite called xpcshell-tst, and during the execution of test
suite running Comm-Centeral Thuderbrid,
I got a "Conditional jump or move depends on uninitialised value(s)" in one of
the file.
STEPS TO REPRODUCE
1. The original bug is filed in mozilla's bugzilla.
https://bugzilla.mozilla.org/show_bug.cgi?id=1952749
2. I ran comm-central thunderbird (compiled locally on my PC) under valgrind
with the following
parameters.:
Please note that I am NOT using mozilla's versatile |mach| command
that can be used to invoke valgrind in a simplistic manner. It has a
shell quoting problem and cannot pass the complext valgrind options
which I use correctly.
So, I opted to rename the original xpcshell binary to xpcshell-bin,
and installs a binary that calls xpcshell-bin under valgrind with
appropriate options.
With this setup, I ran thunderbird's xpcshell-test test suite, and
the suite is executed by thunderbird running under valgrind.
Here is the options that I pass to valgrind.:
run-valgrind-xpcshell invoked ...
sizeof(prepargs)=136
argc=26
finalargs[ 0] = valgrind
finalargs[ 1] = --track-origins=yes
finalargs[ 2] = --trace-children=yes
finalargs[ 3] =
--trace-children-skip=/usr/bin/lsb_release,/usr/bin/hg,/bin/rm,*/bin/certutil,*/bin/pk12util,*/bin/ssltunnel,*/bin/uname,*/bin/which,*/bin/ps,*/bin/grep,*/bin/java,*/fix-stacks,*/firefox/firefox,*/bin/firefox-esr,*/bin/python,*/bin/python3,*/bin/python2,*/bin/python2.7,*/bin/lsb_release,*/bin/bash,*/bin/nodejs,*/bin/node,*/bin/xpcshell,python3,/bin/sh
finalargs[ 4] = --vex-iropt-register-updates=allregs-at-mem-access
finalargs[ 5] = --smc-check=all-non-file
finalargs[ 6] = --gen-suppressions=all
finalargs[ 7] = --show-mismatched-frees=no
finalargs[ 8] = --fair-sched=yes
finalargs[ 9] = --num-callers=50
finalargs[ 10] =
--suppressions=/NEW-SSD/NREF-COMM-CENTRAL/mozilla/build/valgrind/cross-architecture.sup
finalargs[ 11] =
--suppressions=/NEW-SSD/moz-obj-dir/objdir-tb3/_valgrind/i386-pc-linux-gnu.sup
finalargs[ 12] = --suppressions=/home/ishikawa/Dropbox/myown.sup
finalargs[ 13] = --show-possibly-lost=no
finalargs[ 14] = --malloc-fill=0xA5
finalargs[ 15] = --free-fill=0xC3
finalargs[ 16] = /NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/xpcshell-bin
finalargs[ 17] = -g
finalargs[ 18] = /NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin
finalargs[ 19] = -a
finalargs[ 20] = /NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin
finalargs[ 21] = -m
finalargs[ 22] = -e
finalargs[ 23] = const _HEAD_JS_PATH =
"/NEW-SSD/NREF-COMM-CENTRAL/mozilla/testing/xpcshell/head.js";
finalargs[ 24] = -e
finalargs[ 25] = const _MOZINFO_JS_PATH =
"/NEW-SSD/moz-obj-dir/objdir-tb3/temp/xpc-profile-g5u3x9tf/mozinfo.json";
finalargs[ 26] = -e
finalargs[ 27] = const _PREFS_FILE =
"/NEW-SSD/moz-obj-dir/objdir-tb3/temp/user.js";
finalargs[ 28] = -e
finalargs[ 29] = const _TESTING_MODULES_DIR =
"/NEW-SSD/moz-obj-dir/objdir-tb3/_tests/modules/";
finalargs[ 30] = -f
finalargs[ 31] = /NEW-SSD/NREF-COMM-CENTRAL/mozilla/testing/xpcshell/head.js
finalargs[ 32] = -e
finalargs[ 33] = const _HEAD_FILES =
["/NEW-SSD/moz-obj-dir/objdir-tb3/_tests/xpcshell/comm/mailnews/imap/test/unit/head_imap_maildir.js"];
finalargs[ 34] = -e
finalargs[ 35] = const _JSDEBUGGER_PORT = 0;
finalargs[ 36] = -e
finalargs[ 37] = const _TEST_FILE =
["/NEW-SSD/moz-obj-dir/objdir-tb3/_tests/xpcshell/comm/mailnews/imap/test/unit/test_localToImapFilter.js"];
finalargs[ 38] = -e
finalargs[ 39] = const _TEST_NAME =
"xpcshell-maildir.ini:comm/mailnews/imap/test/unit/test_localToImapFilter.js";
finalargs[ 40] = -e
finalargs[ 41] = _execute_test(); quit(0);
Please note that I am using fair scheduling which has run thunderbird (and
presumably Firefox) without issues regarding thread scheduling issues before.
But this time, it may not work as expected.
OBSERVED RESULT
EXPECTED RESULT
SOFTWARE/OS VERSIONS
uname -a
Linux ip030 6.12.12-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.12.12-1 (2025-02-02)
x86_64 GNU/Linux
ADDITIONAL INFORMATION
To summarize the issue discussed in mozilla's bugzilla,
thunderbird creates a lambda/function that is then passed to a different thread
using SyncRunnable::DispatchToThread(), and
usually the different thread executes that function in the context of THAT
thread, and then returns the function value if any.
The calling thread is blocked as the SyncRunnable::DispatchToThread() name
suggests (so it seems).|
However, somehow under valgrind, this blocking of the calling thread of
SyncRunnable::DisaptachToThread() does not occur and it does not wait for the
completion of the function invocation that is to be done on a different
thread.
Thunderbird merrily proceeds without waiting, so the variable(s) that are
assigned values in the function/lambda are not
assigned a value yet, and I see "Conditional jump or move depends on
uninitialised value(s)".
I have investigated this far.
I am puzzled since I have not seen this happen before. I have run thunderbird
under vlgrind on and off for the last 7-8 years, or maybe longer. But for the
last 10 months or so, I did not because of an issue maybe timing issue inside
the GUI library. (See https://bugzilla.mozilla.org/show_bug.cgi?id=1880148 )
I say the problem was with thunderbird because the issue discussed there
happened with gdb, strace, and valgrind. Basically, slowdown caused by these
tools cause the context menu system misbehave. It was NOT valgrind issue.
I can't rule out this particular issue crept in the last 10 months.
BUT there were a few old code with the same pattern (create a lambda/function
and then pass it to a different thread for execution in the context of the
different thread, and wait for it).
Moreover, there ARE tons of such usages in firefox code base.
So I think the code pattern is correct, and it only now happens that valgrind
somehow mishandles the
thread switch issue completely.
Does anything in the newer version (3.24, 3.25GIT) ring a bell?
I wonder if I should change "--fair-sched=yes", but I see no reason that it
will solve the current issue.
I see the same issue under 3.24 and 3.25 GIT.
Thank you again for offering this great tool to the programming community.
--
You are receiving this mail because:
You are watching all bug changes.
