Bug 357673

Summary:	crash if I try to run valgrind with a binary link with libcurl
Product:	[Developer tools] valgrind	Reporter:	Arthur LAMBERT <lambertarthur22>
Component:	general	Assignee:	Julian Seward <jseward>
Status:	RESOLVED FIXED
Severity:	crash
Priority:	NOR
Version First Reported In:	3.10.0
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

Description Arthur LAMBERT 2016-01-07 22:48:32 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 (which uses openssl), 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.
arch : ARM
platform : custom embedded system built with buildroot

Thanks,
Arthur.

Reproducible: Always

Steps to Reproduce:
1. build a binary link with libcurl with openssl support using buildroot
2. run valgrind on this binary
3.

Actual Results:  
# 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.


I only reproduce the bug on ARM. I will tryto make the test on x86 this week.

Comment 1 Julian Seward 2016-08-03 12:03:58 UTC

This was a bug caused by incorrectly accepting a 32 bit v8 crypto instruction
when it was not in fact supported.  The invalid-IR failure was fixed in vex r3233.
Implementation of 32 bit v8 crypto instructions is currently in progress, with
AESD/AESE/AESMC/AESIMC now implemented.

Comment 2 Arthur LAMBERT 2016-08-03 13:09:32 UTC

Hi Julian,

It is possible to have a link to get the patch and test them manually until the official integration  or is it too soon ?

Comment 3 Julian Seward 2016-09-16 13:56:23 UTC

(In reply to Arthur LAMBERT from comment #2)
> It is possible to have a link to get the patch and test them manually until
> the official integration  or is it too soon ?

Download and build the trunk:
svn co svn://svn.valgrind.org/valgrind/trunk
cd trunk
./autogen.sh
then configure and build as normal.