(2012/12/18 8:07), Philippe Waroquiers wrote:
> Destruction of unknown cond var is probably/maybe bug
> https://bugs.kde.org/show_bug.cgi?id=307082
>
I have produced a patch to take care of the issue.
But before that, I have a question.
Q1: Why does valgrind not complain if I compile & link
Marc's code (in the bug entry which was given as a reminder that
"unknown cond var" may be a bug or false positive.) in the following manner,
cc -o /tmp/a.out marc.c
(Note that there is no -lpthread parameter)
and then run
valgrind --tool=helgrind /tmp/a.out
There is no warning or error at all. (under linux, that is).
I wonder WHICH library is used for pthread_cond_init() and friends.
This is just out of curiosity. Not related to the next important
request/question.
Q2: I have produced a work-in-progress patch to take care this issue.
I wonder if the developers in the know can take a look and improve it.
The patch is posted to the bug entry
https://bugs.kde.org/show_bug.cgi?id=307082
I also posted the output of regression test for helgind.
Before the patch, valgrind 3.8.1 reported the issue as Marc reported.
(marc.c is the code reported by marc)
ishikawa@debian-vbox-ci:/tmp$ gcc -g -o /tmp/a.out -lpthread
~/Dropbox/marc.c
ishikawa@debian-vbox-ci:/tmp$ /tmp/a.out
ishikawa@debian-vbox-ci:/tmp$ valgrind --tool=helgrind /tmp/a.out
==22785== Helgrind, a thread error detector
==22785== Copyright (C) 2007-2012, and GNU GPL'd, by OpenWorks LLP et al.
==22785== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==22785== Command: /tmp/a.out
==22785==
==22785== ---Thread-Announcement------------------------------------------
==22785==
==22785== Thread #1 is the program's root thread
==22785==
==22785== ----------------------------------------------------------------
==22785==
==22785== Thread #1: pthread_cond_destroy: destruction of unknown cond var
==22785== at 0x4027B1E: pthread_cond_destroy_WRK (hg_intercepts.c:940)
==22785== by 0x402987F: pthread_cond_destroy@* (hg_intercepts.c:958)
==22785== by 0x80484F4: main (marc.c:6)
==22785==
==22785==
==22785== For counts of detected and suppressed errors, rerun with: -v
==22785== Use --history-level=approx or =none to gain increased speed, at
==22785== the cost of reduced accuracy of conflicting-access information
==22785== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
But after the patch, it runs as follows. See the false positive warning
is no longer there.
$ valgrind --tool=helgrind /tmp/a.out
==25080== Helgrind, a thread error detector
==25080== Copyright (C) 2007-2012, and GNU GPL'd, by OpenWorks LLP et al.
==25080== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==25080== Command: /tmp/a.out
==25080==
==25080==
==25080== For counts of detected and suppressed errors, rerun with: -v
==25080== Use --history-level=approx or =none to gain increased speed, at
==25080== the cost of reduced accuracy of conflicting-access information
==25080== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
ishikawa@debian-vbox-ci:/tmp$
Not sure, though if it works with the initialized data as in
pthread_mutex_t mut = PTHREAD_MUTEX_INITIALIZER;
pthread_cond_t cond = PTHREAD_COND_INITIALIZER;
[Note: No it can't be obviously. This is because the mapping of cond var
to CVInfo structure can not be done explicitly using the timing of
pthread_cond_init(). I tested it to confirm this observation by a slight
modification of marc's code.]
I really want to get down to the bottom of the problem I was analyzing
(random crashes of mozilla thunderbird mail client, and I suspect
races because it is random.) Seeing a mail client crash when it was
exiting is very distressful: I have to wonder if the e-mail from an
important client that just arrived is stored properly in the file or
not before the crash :-(
So if developers in the know can take a look at the patch, and offer
suggestions for improvement I am all ears so that I can use a patched
3.8.1-b to dig down the problem with mozilla thunderbird (with the
reduced clutter of "unknown cond var" and I will use the suggestion to
check for task id or something using vgdbserver feature. Or maybe I
can print the address of cond variables by modifying the code.
Q3:
> I have in a corner a patch for helgrind which print symbolic information
> for the lock addresses. Patch not finished yet.
>
> Would be worth filing a wish bug in bugzilla telling that helgrind
> could use --read-var-info=yes to show more info about
> cond var addresses, lock addresses, etc.
>
> Philippe
You mean helgrind can't use the information obtained by
--read-var-info=yes (!?). That is tough, indeed.
Maybe that is why the current helgrind doesn't even seem to attempt to
print the address of cond var even in the form of offset in heap, or
offset in the stack, etc.
TIA
------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
