|
From: Ali J. <a.j...@gm...> - 2009-01-23 13:16:17
Attachments:
helgrind-laog-deletion-bug.patch
|
Hello, When I ran unit test [1] - test 0, I got an error as following: [1] http://data-race-test.googlecode.com ========================================================================= ~/valgrind/unittest$ helgrind ./racecheck_unittest 0 ==22433== Helgrind, a thread error detector. ==22433== Copyright (C) 2007-2008, and GNU GPL'd, by OpenWorks LLP et al. ==22433== Using LibVEX rev 1878, a library for dynamic binary translation. ==22433== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP. ==22433== Using valgrind-3.4.0, a dynamic binary instrumentation framework. ==22433== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al. ==22433== For more details, rerun with: -v ==22433== test00: negative GLOB=0 --22433-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --22433-- si_code=1; Faulting address: 0x10; sp: 0x62e67e88 valgrind: the 'impossible' happened: Killed by fatal signal ==22433== at 0x38039051: vgPlain_lookupFM (m_wordfm.c:659) ==22433== by 0x62E6793F: ??? sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==22433== at 0x4026BD4: pthread_mutex_destroy (hg_intercepts.c:371) ==22433== by 0x8057BE0: Mutex::~Mutex() (thread_wrappers_pthread.h:154) ==22433== by 0x41B1D68: exit (in /lib/tls/i686/cmov/libc-2.8.90.so) ==22433== by 0x419968C: (below main) (in /lib/tls/i686/cmov/libc-2.8.90.so) Note: see also the FAQ.txt in the source distribution. It contains workarounds to several common problems. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what Linux distro you are using. Thanks. ============================================================================ ====== Test 0's destructor is trying to delete a mutex, but the whole program never used mutexes. So, Helgrind's loag is not initialized and trying to delete the mutex faults. The attached patch should initializes loag and laog_exposition just before laog__preds, which did the faulting lookup. Thanks Ali |
|
From: Julian S. <js...@ac...> - 2009-01-24 20:30:41
|
> test00: negative
> GLOB=0
> --22433-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV)
> - exiting
> --22433-- si_code=1; Faulting address: 0x10; sp: 0x62e67e88
> Test 0's destructor is trying to delete a mutex, but the whole program
> never used mutexes.
> So, Helgrind's loag is not initialized and trying to delete the mutex
> faults.
I understand what you're saying, but I can't reproduce this failure:
sewardj@zazenhausen:~/DaRaT/unittest$
valgrind-3.4.0 --tool=helgrind ./racecheck_unittest 0
==24354== Helgrind, a thread error detector.
==24354== Copyright (C) 2007-2008, and GNU GPL'd, by OpenWorks LLP et al.
==24354== Using LibVEX rev 1878, a library for dynamic binary translation.
==24354== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
==24354== Using valgrind-3.4.0, a dynamic binary instrumentation framework.
==24354== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et al.
==24354== For more details, rerun with: -v
==24354==
test00: negative
GLOB=0
==24354==
==24354== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Do I need to build racecheck_unittest in some special way? I simply
checked out the sources and did 'make' in the unittest directory;
maybe there is some other config option needed? I believe there are
some magic configuration options for racecheck_unittest, but I don't
know what they are.
J
|
|
From: Ali J. <a.j...@gm...> - 2009-01-25 22:15:40
|
Sorry, we used a very old revision of unittest. The bug can be reproduced
until revision 382.
Since revision 383, every printf is synchronized via mutex and helgrind's
loag gets initialized in every case.
The following simple program also triggers the described behaviour:
#include <pthread.h>
pthread_mutex_t mutex;
int main(int argc, char* argv[])
{
pthread_mutex_init(&mutex, NULL);
pthread_mutex_destroy(&mutex);
return 0;
}
Ali
> -----Original Message-----
> From: Julian Seward [mailto:js...@ac...]
> Sent: Samstag, 24. Januar 2009 21:30
> To: val...@li...
> Cc: Ali Jannesari
> Subject: Re: [Valgrind-developers] Bug in Helgrind
>
>
> > test00: negative
> > GLOB=0
> > --22433-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11
> (SIGSEGV)
> > - exiting
> > --22433-- si_code=1; Faulting address: 0x10; sp: 0x62e67e88
>
> > Test 0's destructor is trying to delete a mutex, but the whole
> program
> > never used mutexes.
> > So, Helgrind's loag is not initialized and trying to delete the mutex
> > faults.
>
> I understand what you're saying, but I can't reproduce this failure:
>
> sewardj@zazenhausen:~/DaRaT/unittest$
> valgrind-3.4.0 --tool=helgrind ./racecheck_unittest 0
> ==24354== Helgrind, a thread error detector.
> ==24354== Copyright (C) 2007-2008, and GNU GPL'd, by OpenWorks LLP et
> al.
> ==24354== Using LibVEX rev 1878, a library for dynamic binary
> translation.
> ==24354== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
> ==24354== Using valgrind-3.4.0, a dynamic binary instrumentation
> framework.
> ==24354== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et
> al.
> ==24354== For more details, rerun with: -v
> ==24354==
> test00: negative
> GLOB=0
> ==24354==
> ==24354== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from
> 0)
>
> Do I need to build racecheck_unittest in some special way? I simply
> checked out the sources and did 'make' in the unittest directory;
> maybe there is some other config option needed? I believe there are
> some magic configuration options for racecheck_unittest, but I don't
> know what they are.
>
> J
|
|
From: Julian S. <js...@ac...> - 2009-01-26 10:46:29
|
Fixed (r9063); can you test?
Thanks for the bug report and test cases.
J
On Sunday 25 January 2009, Ali Jannesari wrote:
> Sorry, we used a very old revision of unittest. The bug can be reproduced
> until revision 382.
> Since revision 383, every printf is synchronized via mutex and helgrind's
> loag gets initialized in every case.
>
> The following simple program also triggers the described behaviour:
>
> #include <pthread.h>
>
> pthread_mutex_t mutex;
>
> int main(int argc, char* argv[])
> {
> pthread_mutex_init(&mutex, NULL);
> pthread_mutex_destroy(&mutex);
> return 0;
> }
>
>
> Ali
>
> > -----Original Message-----
> > From: Julian Seward [mailto:js...@ac...]
> > Sent: Samstag, 24. Januar 2009 21:30
> > To: val...@li...
> > Cc: Ali Jannesari
> > Subject: Re: [Valgrind-developers] Bug in Helgrind
> >
> > > test00: negative
> > > GLOB=0
> > > --22433-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11
> >
> > (SIGSEGV)
> >
> > > - exiting
> > > --22433-- si_code=1; Faulting address: 0x10; sp: 0x62e67e88
> > >
> > > Test 0's destructor is trying to delete a mutex, but the whole
> >
> > program
> >
> > > never used mutexes.
> > > So, Helgrind's loag is not initialized and trying to delete the mutex
> > > faults.
> >
> > I understand what you're saying, but I can't reproduce this failure:
> >
> > sewardj@zazenhausen:~/DaRaT/unittest$
> > valgrind-3.4.0 --tool=helgrind ./racecheck_unittest 0
> > ==24354== Helgrind, a thread error detector.
> > ==24354== Copyright (C) 2007-2008, and GNU GPL'd, by OpenWorks LLP et
> > al.
> > ==24354== Using LibVEX rev 1878, a library for dynamic binary
> > translation.
> > ==24354== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
> > ==24354== Using valgrind-3.4.0, a dynamic binary instrumentation
> > framework.
> > ==24354== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward et
> > al.
> > ==24354== For more details, rerun with: -v
> > ==24354==
> > test00: negative
> > GLOB=0
> > ==24354==
> > ==24354== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from
> > 0)
> >
> > Do I need to build racecheck_unittest in some special way? I simply
> > checked out the sources and did 'make' in the unittest directory;
> > maybe there is some other config option needed? I believe there are
> > some magic configuration options for racecheck_unittest, but I don't
> > know what they are.
> >
> > J
>
> ---------------------------------------------------------------------------
>--- This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Ali J. <a.j...@gm...> - 2009-01-26 12:55:17
|
Hi,
It is working....
Ali
> -----Original Message-----
> From: Julian Seward [mailto:js...@ac...]
> Sent: Montag, 26. Januar 2009 11:46
> To: val...@li...
> Cc: Ali Jannesari
> Subject: Re: [Valgrind-developers] Bug in Helgrind
>
>
> Fixed (r9063); can you test?
>
> Thanks for the bug report and test cases.
>
> J
>
> On Sunday 25 January 2009, Ali Jannesari wrote:
> > Sorry, we used a very old revision of unittest. The bug can be
> reproduced
> > until revision 382.
> > Since revision 383, every printf is synchronized via mutex and
> helgrind's
> > loag gets initialized in every case.
> >
> > The following simple program also triggers the described behaviour:
> >
> > #include <pthread.h>
> >
> > pthread_mutex_t mutex;
> >
> > int main(int argc, char* argv[])
> > {
> > pthread_mutex_init(&mutex, NULL);
> > pthread_mutex_destroy(&mutex);
> > return 0;
> > }
> >
> >
> > Ali
> >
> > > -----Original Message-----
> > > From: Julian Seward [mailto:js...@ac...]
> > > Sent: Samstag, 24. Januar 2009 21:30
> > > To: val...@li...
> > > Cc: Ali Jannesari
> > > Subject: Re: [Valgrind-developers] Bug in Helgrind
> > >
> > > > test00: negative
> > > > GLOB=0
> > > > --22433-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11
> > >
> > > (SIGSEGV)
> > >
> > > > - exiting
> > > > --22433-- si_code=1; Faulting address: 0x10; sp: 0x62e67e88
> > > >
> > > > Test 0's destructor is trying to delete a mutex, but the whole
> > >
> > > program
> > >
> > > > never used mutexes.
> > > > So, Helgrind's loag is not initialized and trying to delete the
> mutex
> > > > faults.
> > >
> > > I understand what you're saying, but I can't reproduce this
> failure:
> > >
> > > sewardj@zazenhausen:~/DaRaT/unittest$
> > > valgrind-3.4.0 --tool=helgrind ./racecheck_unittest 0
> > > ==24354== Helgrind, a thread error detector.
> > > ==24354== Copyright (C) 2007-2008, and GNU GPL'd, by OpenWorks LLP
> et
> > > al.
> > > ==24354== Using LibVEX rev 1878, a library for dynamic binary
> > > translation.
> > > ==24354== Copyright (C) 2004-2008, and GNU GPL'd, by OpenWorks LLP.
> > > ==24354== Using valgrind-3.4.0, a dynamic binary instrumentation
> > > framework.
> > > ==24354== Copyright (C) 2000-2008, and GNU GPL'd, by Julian Seward
> et
> > > al.
> > > ==24354== For more details, rerun with: -v
> > > ==24354==
> > > test00: negative
> > > GLOB=0
> > > ==24354==
> > > ==24354== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0
> from
> > > 0)
> > >
> > > Do I need to build racecheck_unittest in some special way? I
> simply
> > > checked out the sources and did 'make' in the unittest directory;
> > > maybe there is some other config option needed? I believe there
> are
> > > some magic configuration options for racecheck_unittest, but I
> don't
> > > know what they are.
> > >
> > > J
> >
> > ---------------------------------------------------------------------
> ------
> >--- This SF.net email is sponsored by:
> > SourcForge Community
> > SourceForge wants to tell your story.
> > http://p.sf.net/sfu/sf-spreadtheword
> > _______________________________________________
> > Valgrind-developers mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|