|
From: Will S. <wil...@vn...> - 2015-05-07 15:18:04
|
On Tue, 2015-05-05 at 16:57 -0500, Will Schmidt wrote: > add updated pth_cond_destroy_busy for ppc64 (BE). > For BE, the summary reports "6 errors" rather than "3 errors". > ppc64LE seems OK with the existing "3 errors" value. > > I've not done a deep dive to verify the output, but expect this > is accurate. > > Signed-off-by: Will Schmidt <wil...@vn...> > --- <snip> > diff --git a/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64be b/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64be > new file mode 100644 > index 0000000..2da688e > --- /dev/null > +++ b/helgrind/tests/pth_cond_destroy_busy.stderr.exp-ppc64be > @@ -0,0 +1,50 @@ > + > +---Thread-Announcement------------------------------------------ > + > +Thread #x is the program's root thread > + > +---Thread-Announcement------------------------------------------ > + > +Thread #x was created > + ... > + by 0x........: pthread_create@* (hg_intercepts.c:...) > + by 0x........: main (pth_cond_destroy_busy.c:45) > + > +---------------------------------------------------------------- > + > +Possible data race during read of size 1 at 0x........ by thread #x > +Locks held: none > + at 0x........: my_memcmp (hg_intercepts.c:...) > + by 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...) > + by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...) > + by 0x........: main (pth_cond_destroy_busy.c:52) > + > +This conflicts with a previous write of size 4 by thread #x > +Locks held: none > + ... > + by 0x........: pthread_cond_wait_WRK (hg_intercepts.c:...) > + by 0x........: pthread_cond_wait@* (hg_intercepts.c:...) > + by 0x........: thread_func (pth_cond_destroy_busy.c:31) > + by 0x........: mythread_wrapper (hg_intercepts.c:...) > + ... > + Address 0x........ is 4 bytes inside data symbol "s_cond" > + > +---------------------------------------------------------------- > + > +Thread #x: pthread_cond_destroy: destruction of condition variable being waited upon > + at 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...) > + by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...) > + by 0x........: main (pth_cond_destroy_busy.c:52) > + > +---------------------------------------------------------------- > + > +Thread #x's call to pthread_cond_destroy failed > + with error code 16 (EBUSY: Device or resource busy) > + at 0x........: pthread_cond_destroy_WRK (hg_intercepts.c:...) > + by 0x........: pthread_cond_destroy@* (hg_intercepts.c:...) > + by 0x........: main (pth_cond_destroy_busy.c:52) > + > +First pthread_cond_destroy() call returned EBUSY. > +Second pthread_cond_destroy() call returned success. > + > +ERROR SUMMARY: 6 errors from 3 contexts (suppressed: 0 from 0) Looking for some input on fixing this one up further. The only actual difference between this and the existing .exp is for ppc64BE, where the SUMMARY line reports 6 errors from 3 contexts, versus the baseline 3 errors from 3 contexts. i.e. (ppc64BE) ERROR SUMMARY: 6 errors from 3 contexts (suppressed: 0 from 0) (ppc64LE and other arches). ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0) I see two good options, one bad option. Either way I expect to add/modify a filter to modify the "* errors from * contexts" portion. So I could: replace the "6 errors ..." with "3 errors",.. this is the simplest change, but seems like bad form to change that result to an arbitrary non-zero value like that. replace the "* errors from * contexts" with zeros, similar to the suppressed portion of the summary, and add a new .exp-ppc64 to compare the zeros against. replace the string with zeros, and modify the existing .exp file. This is what I'm leaning towards, but really depends on whether those non-zero values are important. Any thoughts or preferences? Thanks, -Will |