Hi, I have almost the same bug found here : https://bugzilla.redhat.com/show_bug.cgi?id=810992 When I link my software with libcurl, valgrind is not able to run correctly : # valgrind ./test ==4659== Memcheck, a memory error detector ==4659== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==4659== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info ==4659== Command: ./nyx_core_dev ==4659== ==4659== Invalid read of size 4 ==4659== at 0x4005404: _dl_get_ready_to_run (in /lib/ld-uClibc-1.0.5.so) ==4659== Address 0x7dbb96f4 is on thread 1's stack ==4659== 20 bytes below stack pointer ==4659== IR SANITY CHECK FAILURE IRSB { t0:V128 t1:V128 t2:V128 t3:I32 IR-NoOp IR-NoOp IR-NoOp IR-NoOp IR-NoOp IR-NoOp IR-NoOp IR-NoOp IR-NoOp IR-NoOp IR-NoOp IR-NoOp IR-NoOp IR-NoOp IR-NoOp ------ IMark(0x4B0EEC8, 4, 0) ------ PUT(64) = 0x4B0EECC:I32 PUT(68) = 0x4B127B8:I32 ------ IMark(0x4B127B8, 4, 0) ------ t0 = GET:V128(128) t1 = GET:V128(128) PUT(128) = t2 PUT(68) = 0x4B127BC:I32 ------ IMark(0x4B127BC, 4, 0) ------ t3 = GET:I32(64) PUT(68) = t3 PUT(68) = GET:I32(68); exit-Return } IN STATEMENT: PUT(128) = t2 ERROR = IRTemp use before def in IRExpr vex: the `impossible' happened: sanityCheckFail: exiting due to bad IR vex storage: T total 28036856 bytes allocated vex storage: P total 0 bytes allocated valgrind: the 'impossible' happened: LibVEX called failure_exit(). host stacktrace: ==4659== at 0x3805E89C: ??? (in /usr/lib/valgrind/memcheck-arm-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==4659== at 0x4B0EEC8: OPENSSL_cpuid_setup (in /usr/lib/libcrypto.so.1.0.0) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. 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 OS and version you are using. Thanks. Valgrind version : 3.10.1 The bug was fixed in valgrind 3.8.X in the previous bug. Thanks, Arthur.
The current release in fedora is valgrind-3.11.0-1.fc23 have you replicated the issue with that version? Could you show what the test binary does exactly if it still happens with that version? There also seems to be something odd going on with your binary since it is using uClibc ld.so instead of the fedora glibc ld.so.
In fact the reason is quite simple. I am not using fedora to running the test. I am using an ARM linux system build with buildroot. I put the bug here because this is the only place where I find bug which seems to be very close from my issue. this is defintely not a fedora issue but a valgrind issue. Do I have wrong about the place to share this bug ? Should I use the valgrind maling list instead perhaps ?
(In reply to Arthur LAMBERT from comment #2) > this is defintely not a fedora issue but a valgrind issue. > > Do I have wrong about the place to share this bug ? Should I use the > valgrind maling list instead perhaps ? In that case, if you could file it upstream that would be helpful: https://bugs.kde.org/enter_bug.cgi?product=valgrind&format=guided
(In reply to Mark Wielaard from comment #3) > (In reply to Arthur LAMBERT from comment #2) > > this is defintely not a fedora issue but a valgrind issue. > > > > Do I have wrong about the place to share this bug ? Should I use the > > valgrind maling list instead perhaps ? > > In that case, if you could file it upstream that would be helpful: > https://bugs.kde.org/enter_bug.cgi?product=valgrind&format=guided Done ! https://bugs.kde.org/show_bug.cgi?id=357673 I guess that I can remove my initial bug from here ?
Thanks. Closing here. Bug moved upstream.