Summary: | drd cond_post_wait gets wrong (?) condition on s390x z13 system | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Mark Wielaard <mark> |
Component: | drd | Assignee: | Andreas Arnez <arnez> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | arnez |
Priority: | NOR | ||
Version First Reported In: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Other | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: | |||
Attachments: | Patch for fixing the drd test suite fails |
Description
Mark Wielaard
2019-05-20 13:53:27 UTC
One odd thing is that if you try to add some extra debug statements like: diff --git a/drd/drd_pthread_intercepts.c b/drd/drd_pthread_intercepts.c index d6abd4368..b15b75945 100644 --- a/drd/drd_pthread_intercepts.c +++ b/drd/drd_pthread_intercepts.c @@ -1080,9 +1080,11 @@ int pthread_cond_wait_intercept(pthread_cond_t *cond, pthread_mutex_t *mutex) int ret; OrigFn fn; VALGRIND_GET_ORIG_FN(fn); + printf ("pthread_cond_wait_intercept pre cond: %p\n", cond); VALGRIND_DO_CLIENT_REQUEST_STMT(VG_USERREQ__PRE_COND_WAIT, cond, mutex, DRD_(mutex_type)(mutex), 0, 0); CALL_FN_W_WW(ret, fn, cond, mutex); + printf ("pthread_cond_wait_intercept post cond: %p\n", cond); VALGRIND_DO_CLIENT_REQUEST_STMT(VG_USERREQ__POST_COND_WAIT, cond, mutex, 1, 0, 0); return ret; Note that now the --trace-cond=yes debug statements seem to print the correct cond address. But the new printf debug statements print the wrong cond addresses ??? So it might be some strange interaction with the VALGRIND_DO_CLIENT_REQUEST_STMT and CALL_FN_W_WW macros? Have you considered to change ", cond" into ", &cond" in the printf() statement? (In reply to Bart Van Assche from comment #2) > Have you considered to change ", cond" into ", &cond" in the printf() > statement? But cond is already a pointer to a pthread_cond_t. I suspect it is some strange interaction between the VALGRIND_GET_ORIG_FN, VALGRIND_DO_CLIENT_REQUEST_STMT and (In reply to Bart Van Assche from comment #2) > Have you considered to change ", cond" into ", &cond" in the printf() > statement? But cond is already a pointer to a pthread_cond_t. And none of the macros seems to take the address of any of its arguments. I suspect it is some strange interaction between the VALGRIND_GET_ORIG_FN, VALGRIND_DO_CLIENT_REQUEST_STMT and CALL_FN_W_WW. Maybe bad register constraints? It replicates on Fedora with CFLAGS=-march=z13 Maybe related, or maybe not. memcheck/tests/warp6.vgtest fails on s390x. Without -march=z13 fn_0, fn_1, fn_2 and fn_3 fail. With -march=z13 fn_0, fn_1, fn_2 and fn_3 also fail, plus fn_10, fn_11 and fn_12. pthread_cond_wait_intercept () wraps a function with 2 arguments. Created attachment 120275 [details]
Patch for fixing the drd test suite fails
This patch fixes the drd test suite fails as well as the "wrap6" fail in my testing.
Tested on a non-z13 system and all wrap testcases PASS now. Also tested on a z13 system with CFLAGS=-march=z13. All wrap tests succeed and the drd failures are gone. (except for drd/tests/tc04_free_lock but that fails for a completely unrelated reason). (In reply to Mark Wielaard from comment #8) > Also tested on a z13 system with CFLAGS=-march=z13. All wrap tests succeed > and the drd failures are gone. Great! I'll push the patch and close this bug early next week then. Pushed as git commit c39ee0c37082e2d1723a8671fca2b3af029e2712. |