Bug 1286960 - Valgrind dies with error with libcurl
Valgrind dies with error with libcurl
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: valgrind (Show other bugs)
rawhide
arm Linux
unspecified Severity high
: ---
: ---
Assigned To: Mark Wielaard
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-12-01 03:55 EST by Arthur LAMBERT
Modified: 2016-01-07 18:29 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-01-07 18:29:11 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 357673 None None None 2016-01-07 18:29 EST

  None (edit)
Description Arthur LAMBERT 2015-12-01 03:55:07 EST
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.
Comment 1 Mark Wielaard 2016-01-07 08:53:04 EST
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.
Comment 2 Arthur LAMBERT 2016-01-07 16:43:44 EST
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 ?
Comment 3 Mark Wielaard 2016-01-07 16:50:37 EST
(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
Comment 4 Arthur LAMBERT 2016-01-07 17:49:30 EST
(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 ?
Comment 5 Mark Wielaard 2016-01-07 18:29:11 EST
Thanks. Closing here. Bug moved upstream.

Note You need to log in before you can comment on or make changes to this bug.