Red Hat Bugzilla – Bug 1286960
Valgrind dies with error with libcurl
Last modified: 2016-01-07 18:29:11 EST
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== 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
IR SANITY CHECK FAILURE
t0:V128 t1:V128 t2:V128 t3:I32
------ 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
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().
==4659== at 0x3805E89C: ??? (in /usr/lib/valgrind/memcheck-arm-linux)
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.
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:
(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:
I guess that I can remove my initial bug from here ?
Thanks. Closing here. Bug moved upstream.