| Summary: | valgrind (vex) crashes because isZeroU happened | ||
|---|---|---|---|
| Product: | [Developer tools] valgrind | Reporter: | Darshit Shah <darnir> |
| Component: | vex | Assignee: | Julian Seward <jseward> |
| Status: | RESOLVED FIXED | ||
| Severity: | crash | CC: | amrmlevi, ankurs47, contacts, craigkewley, cravchik, darnir, dirk, flo2030, gabriel.montauro, miabraha, tmpsantos |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Arch Linux | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Darshit Shah
2015-12-08 15:03:52 UTC
I get a similar crash with Valgrind 3.11 in libcrypto at the same function call, ecp_nistz256_avx2_select_w7. I'm running Kubuntu 15.10. I get a similar crash on Arch. valgrind 3.11 ==26955== at 0x5EAAF40: ecp_nistz256_avx2_select_w7 (in /usr/lib/libcrypto.so.1.0.0) ==26955== by 0x5E7A5CF: EC_POINT_mul (in /usr/lib/libcrypto.so.1.0.0) ==26955== by 0x5E79416: EC_POINT_new (in /usr/lib/libcrypto.so.1.0.0) ==26955== by 0x5E82E89: EC_KEY_generate_key (in /usr/lib/libcrypto.so.1.0.0) ==26955== by 0x78092A4: ssl3_send_client_key_exchange (in /usr/lib/libssl.so.1.0.0) ==26955== by 0x780CF67: ssl3_connect (in /usr/lib/libssl.so.1.0.0) ==26955== by 0x7817E9B: ssl23_connect (in /usr/lib/libssl.so.1.0.0) ==26955== by 0x6265A03: ??? (in /usr/lib/libcurl.so.4.4.0) ==26955== by 0x6265FB9: ??? (in /usr/lib/libcurl.so.4.4.0) ==26955== by 0x626967F: ??? (in /usr/lib/libcurl.so.4.4.0) ==26955== by 0x622276D: ??? (in /usr/lib/libcurl.so.4.4.0) ==26955== by 0x6248535: ??? (in /usr/lib/libcurl.so.4.4.0) ==26955== by 0x624915C: curl_multi_perform (in /usr/lib/libcurl.so.4.4.0) ==26955== by 0x623FBFA: curl_easy_perform (in /usr/lib/libcurl.so.4.4.0) I'm getting the same crash on Kubuntu 15.10 with Vlagrind 3.11.0 while trying to analyze the application that uses libcurl: vex: the `impossible' happened: isZeroU vex storage: T total 15579834320 bytes allocated vex storage: P total 640 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==6282== at 0x38083F98: show_sched_status_wrk (m_libcassert.c:343) ==6282== by 0x380840B4: report_and_quit (m_libcassert.c:415) ==6282== by 0x380842F1: panic (m_libcassert.c:491) ==6282== by 0x380842F1: vgPlain_core_panic_at (m_libcassert.c:496) ==6282== by 0x3808431A: vgPlain_core_panic (m_libcassert.c:501) ==6282== by 0x3809F6B2: failure_exit (m_translate.c:740) ==6282== by 0x38148078: vpanic (main_util.c:231) ==6282== by 0x381551DD: isZeroU.isra.16.part.17 (ir_opt.c:1226) ==6282== by 0x38159302: isZeroU (ir_opt.c:1525) ==6282== by 0x38159302: fold_Expr (ir_opt.c:2308) ==6282== by 0x38159F36: subst_and_fold_Stmt (ir_opt.c:2585) ==6282== by 0x38159F36: cprop_BB (ir_opt.c:2794) ==6282== by 0x3815BE48: cheap_transformations (ir_opt.c:6414) ==6282== by 0x3815CE96: do_iropt_BB (ir_opt.c:6608) ==6282== by 0x38145E7C: LibVEX_Translate (main_main.c:916) ==6282== by 0x380A1C3B: vgPlain_translate (m_translate.c:1765) ==6282== by 0x380D294B: handle_chain_me (scheduler.c:1076) ==6282== by 0x380D45AF: vgPlain_scheduler (scheduler.c:1420) ==6282== by 0x380E3926: thread_wrapper (syswrap-linux.c:102) ==6282== by 0x380E3926: run_a_thread_NORETURN (syswrap-linux.c:155) ==6282== by 0x380E3DFA: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:324) ==6282== by 0x3810C60D: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) ==6282== by 0xDEADBEEFDEADBEEE: ??? ==6282== by 0xDEADBEEFDEADBEEE: ??? ==6282== by 0xDEADBEEFDEADBEEE: ??? sched status: running_tid=8 [...] Thread 8: status = VgTs_Runnable (lwpid 6351) ==6282== at 0x9AF5980: ecp_nistz256_avx2_select_w7 (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==6282== by 0x9AD4CEF: EC_POINT_mul (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==6282== by 0x9AD3B36: EC_POINT_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==6282== by 0x9ADD029: EC_KEY_generate_key (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0) ==6282== by 0x11775D94: ssl3_send_client_key_exchange (in /lib/x86_64-linux-gnu/libssl.so.1.0.0) ==6282== by 0x11779857: ssl3_connect (in /lib/x86_64-linux-gnu/libssl.so.1.0.0) ==6282== by 0x11782F3D: ssl23_connect (in /lib/x86_64-linux-gnu/libssl.so.1.0.0) ==6282== by 0xDC4FE83: ossl_connect_step2 (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0) ==6282== by 0xDC50999: ossl_connect_common (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0) ==6282== by 0xDC5433F: Curl_ssl_connect_nonblocking (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0) ==6282== by 0xDC1118C: Curl_http_connect (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0) ==6282== by 0xDC222C0: Curl_protocol_connect (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0) ==6282== by 0xDC3636D: multi_runsingle (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0) ==6282== by 0xDC36F5C: curl_multi_perform (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.3.0) ==6282== [...] (In reply to Darshit Shah from comment #0) > vex: the `impossible' happened: > isZeroU > vex storage: T total 983714392 bytes allocated > vex storage: P total 640 bytes allocated > > valgrind: the 'impossible' happened: > LibVEX called failure_exit(). > > host stacktrace: > ==16723== at 0x38083FA8: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x380840C4: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x38084301: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x3808432A: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x3809F6C2: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x38148008: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x3815516D: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x38159292: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x38159EC6: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x3815BDD8: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x3815CE26: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x38145E0C: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x380A1C4B: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x380D295B: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x380D45BF: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > ==16723== by 0x380E3936: ??? (in /usr/lib/valgrind/memcheck-amd64-linux) > > sched status: > running_tid=1 > > Thread 1: status = VgTs_Runnable (lwpid 16723) > ==16723== at 0x5EA6F40: ecp_nistz256_avx2_select_w7 (in > /usr/lib/libcrypto.so.1.0.0) > ==16723== by 0x5E765CF: EC_POINT_mul (in /usr/lib/libcrypto.so.1.0.0) > ==16723== by 0x5E75416: EC_POINT_new (in /usr/lib/libcrypto.so.1.0.0) > ==16723== by 0x5E7EE89: EC_KEY_generate_key (in > /usr/lib/libcrypto.so.1.0.0) > ==16723== by 0x5B422A4: ssl3_send_client_key_exchange (in > /usr/lib/libssl.so.1.0.0) > ==16723== by 0x5B45F67: ssl3_connect (in /usr/lib/libssl.so.1.0.0) > ==16723== by 0x5B50E9B: ssl23_connect (in /usr/lib/libssl.so.1.0.0) > ==16723== by 0x452B2F: ssl_connect_with_timeout_callback (openssl.c:506) > ==16723== by 0x44DDF3: run_with_timeout (utils.c:2046) > ==16723== by 0x4529A9: ssl_connect_wget (openssl.c:559) > ==16723== by 0x429A0F: establish_connection (http.c:2144) > ==16723== by 0x425BAE: gethttp (http.c:3055) > ==16723== by 0x4243C5: http_loop (http.c:3971) > ==16723== by 0x43FE0E: retrieve_url (retr.c:817) > ==16723== by 0x4365C2: main (main.c:1868) > > Valgrind crashed with the following message when trying to test GNU Wget. > The issue is triggered only by two specific tests that require Wget to > connect to a proxy server over HTTPS. It does not happen during normal > connections to HTTPS servers. Also, the issue occurs only when compiled with > OpenSSL. With GnuTLS there are no problems. > > P.S.: I'm using Valgrind 3.11 on Arch Linux. The version option is not > available in the form. The issue seems to be a regression since it doesn't > come up on an older version (3.7.0) during the CI builds on Travis. > > Reproducible: Always > > Steps to Reproduce: > 1. git clone http://git.savannah.gnu.org/r/wget.git > 2. cd wget > 3. ./bootstrap && ./configure --enable-valgrind-tests --with-ssl=openssl > 4. make check > > Actual Results: > The output present above I just built wget according those instructions on my x86-64. With stock valgrind 3.11.0 I do not get any errors: ============================================================================ Testsuite summary for wget 1.17.1.11-b305 ============================================================================ # TOTAL: 85 # PASS: 71 # SKIP: 14 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 ============================================================================ and ============================================================================ Testsuite summary for wget 1.17.1.11-b305 ============================================================================ # TOTAL: 28 # PASS: 28 # SKIP: 0 # XFAIL: 0 # FAIL: 0 # XPASS: 0 # ERROR: 0 Perhaps it's one of those skipped tests that is failing: SKIP: Test-ftp-iri.px SKIP: Test-ftp-iri-fallback.px SKIP: Test-ftp-iri-recursive.px SKIP: Test-ftp-iri-disabled.px SKIP: Test-idn-headers.px SKIP: Test-idn-meta.px SKIP: Test-idn-cmd.px SKIP: Test-idn-cmd-utf8.px SKIP: Test-idn-robots.px SKIP: Test-idn-robots-utf8.px SKIP: Test-iri.px SKIP: Test-iri-percent.px SKIP: Test-iri-forced-remote.px SKIP: Test-iri-list.px If it's one of these that is failing can you explain what needs to be done to enable those tests? Ah yes, just to make sure: from config.log: configure:4427: checking for valgrind configure:4443: found /home/florian/valgrind/bugzilla/356393/bin/valgrind configure:4455: result: yes The suite runs somewhat fast given that it is supposed to run under valgrind. On my 5 year old laptop I get for "make check" real 2m30.001s user 2m17.587s sys 0m6.500s does that look OK ? This is the guilty code:
case Iop_Xor8:
case Iop_Xor16:
case Iop_Xor32:
case Iop_Xor64:
case Iop_XorV128:
case Iop_XorV256: // <==== selecting this case
/* Xor8/16/32/64/V128(t,t) ==> 0, for some IRTemp t */
if (sameIRExprs(env, e->Iex.Binop.arg1, e->Iex.Binop.arg2)) { // <=== false
e2 = mkZeroOfPrimopResultType(e->Iex.Binop.op);
break;
}
/* XorV128(t,0) ==> t */
if (e->Iex.Binop.op == Iop_XorV128) {
if (isZeroV128(e->Iex.Binop.arg2)) {
e2 = e->Iex.Binop.arg1;
break;
}
//Disabled because there's no known test case right now.
//if (isZeroV128(e->Iex.Binop.arg1)) {
// e2 = e->Iex.Binop.arg2;
// break;
//}
} else {
/* Xor8/16/32/64(0,t) ==> t */
if (isZeroU(e->Iex.Binop.arg1)) { // <=== arriving here
BANG. isZeroU cannot handle Iop_XorV256 hence the assert.
This patch is likely going to fix it (still testing):
Index: VEX/priv/ir_opt.c
===================================================================
--- VEX/priv/ir_opt.c (revision 3206)
+++ VEX/priv/ir_opt.c (working copy)
@@ -2292,8 +2292,15 @@
e2 = mkZeroOfPrimopResultType(e->Iex.Binop.op);
break;
}
+ /* XorV256(t,0) ==> t */
+ if (e->Iex.Binop.op == Iop_XorV256) {
+ if (isZeroV256(e->Iex.Binop.arg2)) {
+ e2 = e->Iex.Binop.arg1;
+ break;
+ }
+ }
/* XorV128(t,0) ==> t */
- if (e->Iex.Binop.op == Iop_XorV128) {
+ else if (e->Iex.Binop.op == Iop_XorV128) {
if (isZeroV128(e->Iex.Binop.arg2)) {
e2 = e->Iex.Binop.arg1;
break;
but the code is UGLY. Comments are out of date and the Boolean IRops And/Or/Xor are handled differently. We really should keep as much code in common as possible.
Extending isZeroU and isOneU to also handle V128 and V256 values makes sense to me.Even if the function name then no longer exactly describes the set of allowed values. Or we can change the function name as there are only aboout 10 invocations. So the ripple is acceptable IMHO.
Arrrgh! Didn't we fix this yet? valgrind 3.11.0 ArchLinux up to date as of today this bug shows up when running valgrind against QML application I just built r15831 and got the same crash when I hit libcurl + ssl. When I comment the network code, valgrind works just fine.
vex: the `impossible' happened:
isZeroU
vex storage: T total 4426865440 bytes allocated
vex storage: P total 640 bytes allocated
valgrind: the 'impossible' happened:
LibVEX called failure_exit().
Thread 3: status = VgTs_Runnable (lwpid 20263)
==20256== at 0x9BB6DC0: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20256== by 0x9B9607F: EC_POINT_mul (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20256== by 0x9B94EC6: EC_POINT_new (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20256== by 0x9B9E439: EC_KEY_generate_key (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==20256== by 0x9876C64: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20256== by 0x987A8A7: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20256== by 0x9884045: ??? (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==20256== by 0x69AC273: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256== by 0x69AC819: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256== by 0x69AFCFF: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256== by 0x696C3CD: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256== by 0x6992175: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256== by 0x6993163: ??? (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256== by 0x6993276: curl_multi_socket_action (in /usr/lib/x86_64-linux-gnu/libcurl.so.4.4.0)
==20256== by 0x57A7C3: mbgl::HTTPCURLContext::perform(int, mbgl::util::RunLoop::Event) (http_request_curl.cpp:191)
==20256== by 0x54E30A: operator() (functional:2267)
==20256== by 0x54E30A: mbgl::util::Watch::onEvent(uv_poll_s*, int, int) (run_loop.cpp:44)
==20256== by 0x5F089D: uv__io_poll (linux-core.c:345)
==20256== by 0x5E7972: uv_run (core.c:341)
==20256== by 0x563814: void mbgl::util::Thread<mbgl::OnlineFileSource::Impl>::run<std::tuple<int>, 0ul>(mbgl::util::ThreadContext, std::tuple<int>&&, std::integer_sequence<unsigned long, 0ul>) (thread.hpp:124)
==20256== by 0x563E09: operator() (thread.hpp:106)
==20256== by 0x563E09: _M_invoke<> (functional:1531)
==20256== by 0x563E09: operator() (functional:1520)
==20256== by 0x563E09: std::thread::_Impl<std::_Bind_simple<mbgl::util::Thread<mbgl::OnlineFileSource::Impl>::Thread<int>(mbgl::util::ThreadContext const&, int&&)::{lambda()#1} ()> >::_M_run() (thread:115)
==20256== by 0x6C83C2F: ??? (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.21)
==20256== by 0x5FEB669: start_thread (pthread_create.c:333)
==20256== by 0x726A01C: clone (clone.S:109)
Fixed, vex r3213. Sorry it took so long to get around to this entirely trivial fix. (In reply to Julian Seward from comment #9) > Fixed, vex r3213. Sorry it took so long to get around to this entirely > trivial fix. Works for me now, thanks for fixing. *** Bug 363497 has been marked as a duplicate of this bug. *** *** Bug 364497 has been marked as a duplicate of this bug. *** |