A new patch was posted to https://bugs.kde.org/show_bug.cgi?id=307082
This cleans up the previous patch that I posted to fix the problem of - pthread_cond_init() was not handled properly, AND - a newly discovered problem of pthread_cond_destroy() erraneously destroying internal data even when pthread_cond_destroy() returns EBUSY and retains the internal data necessary for pthread library operation since there are still tasks waiting on the condition variable. With this, I get a saner output for some sample programs (modified by inserting pthread_cond_destroy() in a place or two) when they are run under helgrind. Sample programs are http://www.cs.kent.edu/~ruttan/sysprog/lectures/multi-thread/multi-thread.html specifically, http://www.cs.kent.edu/~ruttan/sysprog/lectures/multi-thread/thread-pool-server.c Another sample I used is from https://www.securecoding.cert.org/confluence/display/seccode/POS54-C.+Notify+all+POSIX+threads+waiting+on+a+condition+variable+instead+of+a+single+thread but this one caused a hung when I tinkered with pthread_cond_destroy() and I suspect I created an invalid program (rather than helgrind being buggy.). Anyway, I am now running mozilla thunderbird under helgrind to track down a possible thread-related problem again. Again, a review of the patch by developers of valgrind will be appreciated. (Gee, I hate my misspellings and incorrect grammar in my post to https://bugs.kde.org/show_bug.cgi?id=307082 I was not even drinking egg nog. A peril of posting something in the middle of the night when one ought to be sleeping.) TIA (2012/12/23 22:06), Philippe Waroquiers wrote: > On Sun, 2012-12-23 at 03:36 +0900, ISHIKAWA,chiaki wrote: > >> Since the testing is automated (and shrouded in many layers of >> test scripts), it is not easy to figure out how we can >> attach gdb to vgdbserver, and also, it is not quite clear >> how we can prepare the input for vgdbserver/gdb interaction. >> Maybe if I were to start from the scratch, I could do it. >> But mozmill test setup has been there already. > I have no knowledge of mozmill but I suppose it is possible to run one > single specific test of the test suite (up to now, I have never > seen an automatic reg test setup which did not allow to run one > single test). > > So, you should be able to do the same as what you would do for a > "manual" test: just ensure the test tool passes --vgdb-error=0 (or > rather than 0, the error nr you want to dig into). > The app will then stop at the time of the error. > > It looks to me a lot easier/faster than having helgrind reporting > the list of threads waiting (and if you would need other information > such as stack trace, local var values, ... you can look at all this > with GDB). > > > Philippe > > > ------------------------------------------------------------------------------ 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
