Bug 1286960

Summary: Valgrind dies with error with libcurl
Product: [Fedora] Fedora Reporter: Arthur LAMBERT <lambertarthur22>
Component: valgrindAssignee: Mark Wielaard <mjw>
Status: CLOSED UPSTREAM QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: dodji, jakub, lambertarthur22, mjw, mjw
Target Milestone: ---   
Target Release: ---   
Hardware: arm   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-01-07 23:29:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Arthur LAMBERT 2015-12-01 08:55:07 UTC
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 13:53:04 UTC
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 21:43:44 UTC
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 21:50:37 UTC
(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 22:49:30 UTC
(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 23:29:11 UTC
Thanks. Closing here. Bug moved upstream.