Bug 810992 - valgrind dies with ERROR = Iex.Binop: arg tys don't match op tys (OPENSSL_ppc64_probe)
valgrind dies with ERROR = Iex.Binop: arg tys don't match op tys (OPENSSL_ppc...
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: valgrind (Show other bugs)
rawhide
powerpc Linux
high Severity high
: ---
: ---
Assigned To: Mark Wielaard
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-09 15:53 EDT by Karsten Hopp
Modified: 2013-03-10 21:20 EDT (History)
7 users (show)

See Also:
Fixed In Version: valgrind-3.8.1-5
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-01-20 15:37:02 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)
build log (539.88 KB, text/x-log)
2012-04-09 15:53 EDT, Karsten Hopp
no flags Details
the relevant part of the log (5.04 KB, text/plain)
2012-04-09 16:31 EDT, Kamil Dudka
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 308573 None None None 2012-10-17 15:37:27 EDT
KDE Software Compilation 309425 None None None 2012-11-05 09:20:08 EST

  None (edit)
Description Karsten Hopp 2012-04-09 15:53:30 EDT
Created attachment 576295 [details]
build log

Description of problem:
curl-7.25.0-1.fc18 fails to build on PPC, one of the self checks fails:
lib582 returned 1, when expecting 0

Full log attached.

Version-Release number of selected component (if applicable):
curl-7.25.0-1.fc18

How reproducible:
always

Steps to Reproduce:
1.ppc-koji build --scratch f18 curl-7.25.0-1.fc18.src.rpm
2.
3.
  
Actual results:
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=485482

Expected results:


Additional info:
Comment 1 Kamil Dudka 2012-04-09 16:31:15 EDT
Created attachment 576300 [details]
the relevant part of the log
Comment 2 Kamil Dudka 2012-04-09 16:32:54 EDT
This seems to be a valgrind issue.  It panics on execution of OPENSSL_cpuid_setup (in /usr/lib/libcrypto.so.1.0.1).
Comment 4 Mark Wielaard 2012-10-08 11:33:32 EDT
Same issue occurs against valgrind-3.8.1:
http://ppc.koji.fedoraproject.org/koji/getfile?taskID=730100&name=build.log

../libtool --mode=execute /usr/bin/valgrind --tool=memcheck --leak-check=yes --num-callers=16 --log-file=log/valgrind582 ./libtest/lib582 Sftp://127.0.0.1:3299/builddir/build/BUILD/curl-7.27.0/tests/log/upload582.txt /builddir/build/BUILD/curl-7.27.0/tests/log/file582.txt mockbuild: >log/stdout582 2>log/stderr582
lib582 returned 1, when expecting 0
 exit FAILED
== Contents of files in the log/ dir after test 582
=== Start of file file582.txt
 Moooooooooooo
  upload this
=== End of file file582.txt
=== Start of file stderr582
 URL: Sftp://127.0.0.1:3299/builddir/build/BUILD/curl-7.27.0/tests/log/upload582.txt
 Set to upload 27 bytes
 * About to connect() to 127.0.0.1 port 3299 (#0)
 *   Trying 127.0.0.1...
 * connected
 * Connected to 127.0.0.1 (127.0.0.1) port 3299 (#0)
=== End of file stderr582
=== Start of file valgrind582
 ==44318== Memcheck, a memory error detector
 ==44318== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
 ==44318== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
 ==44318== Command: /builddir/build/BUILD/curl-7.27.0/tests/libtest/.libs/lt-lib582 Sftp://127.0.0.1:3299/builddir/build/BUILD/curl-7.27.0/tests/log/upload582.txt /builddir/build/BUILD/curl-7.27.0/tests/log/file582.txt mockbuild:
 ==44318== Parent PID: 44317
 ==44318== 
  op name: And64
  op type is (I64,I64) -> I64
 arg tys are (I32,I64)
 IR SANITY CHECK FAILURE
 IRSB {
    t0:I32   t1:I32   t2:I32   t3:I32   t4:F64   t5:F64   t6:I32   t7:I64
    t8:I32   t9:I32   t10:I32   t11:I32   t12:I32   t13:I32   t14:I32   t15:I32
    t16:I32   t17:I32   t18:I32   t19:I32   t20: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(0xF01D790, 4, 0) ------
    PUT(1172) = 0xF01D794:I32
    PUT(1168) = 0xF01D360:I32
    ------ IMark(0xF01D360, 4, 0) ------
    t9 = 8Uto32(GET:I8(1200))
    t8 = And32(t9,0x3:I32)
    t5 = GET:F64(160)
    t7 = ReinterpF64asI64(t5)
    t4 = I64StoF64(Xor32(t8,And32(Shl32(t8,0x1:I8),0x2:I32)),t7)
    PUT(160) = t4
    PUT(1168) = 0xF01D364:I32
    ------ IMark(0xF01D364, 4, 0) ------
    t10 = GET:I32(16)
    t12 = GET:I32(16)
    t11 = And64(Mux0X(And8(0x20:I8,0x1F:I8),t10,Or32(Shl32(t10,And8(0x20:I8,0x1F:I8)),Shr32(t10,Sub8(0x20:I8,And8(0x20:I8,0x1F:I8))))),0xFFFFFFFF:I64)
    PUT(16) = t11
    PUT(1168) = 0xF01D368:I32
    ------ IMark(0xF01D368, 4, 0) ------
    t18 = 0xFFFFFFFF:I32
    t15 = t18
    t19 = 0x1:I32
    t16 = t19
    t14 = And32(t16,t15)
    t17 = And32(GET:I32(1172),0xFFFFFFFC:I32)
    if (CmpEQ32(t14,0x0:I32)) { PUT(1168) = 0xF01D36C:I32; exit-Boring } 
    PUT(1168) = t17
    PUT(1168) = GET:I32(1168); exit-Return
 }
 IN STATEMENT:
 t11 = And64(Mux0X(And8(0x20:I8,0x1F:I8),t10,Or32(Shl32(t10,And8(0x20:I8,0x1F:I8)),Shr32(t10,Sub8(0x20:I8,And8(0x20:I8,0x1F:I8))))),0xFFFFFFFF:I64)
 ERROR = Iex.Binop: arg tys don't match op tys
 ... additional details precede BB printout
 vex: the `impossible' happened:
    sanityCheckFail: exiting due to bad IR
 vex storage: T total 163342056 bytes allocated
 vex storage: P total 96 bytes allocated
 valgrind: the 'impossible' happened:
    LibVEX called failure_exit().
 ==44318==    at 0x380649E8: report_and_quit (m_libcassert.c:235)
 ==44318==    by 0x38064C0F: vgPlain_core_panic_at (m_libcassert.c:319)
 ==44318==    by 0x38064C43: vgPlain_core_panic (m_libcassert.c:329)
 ==44318==    by 0x38081AAB: failure_exit (m_translate.c:708)
 ==44318==    by 0x3812101F: vpanic (main_util.c:226)
 ==44318==    by 0x38129EDB: sanityCheckFail (ir_defs.c:3232)
 ==44318==    by 0x3812CDDB: tcExpr (ir_defs.c:3544)
 ==44318==    by 0x3812DFE3: sanityCheckIRSB (ir_defs.c:3649)
 ==44318==    by 0x3811EE9B: LibVEX_Translate (main_main.c:655)
 ==44318==    by 0x3808419F: vgPlain_translate (m_translate.c:1559)
 ==44318==    by 0x380B4C2F: handle_chain_me (scheduler.c:1019)
 ==44318==    by 0x380B695F: vgPlain_scheduler (scheduler.c:1323)
 ==44318==    by 0x380CB3EF: run_a_thread_NORETURN (syswrap-linux.c:103)
 sched status:
   running_tid=1
 Thread 1: status = VgTs_Runnable
 ==44318==    at 0xF01D790: OPENSSL_cpuid_setup (in /usr/lib/libcrypto.so.1.0.1c)
 ==44318==    by 0xF0A2E23: OPENSSL_add_all_algorithms_noconf (in /usr/lib/libcrypto.so.1.0.1c)
 ==44318==    by 0xF402227: libssh2_init (in /usr/lib/libssh2.so.1.0.1)
 ==44318==    by 0xF4022F7: ??? (in /usr/lib/libssh2.so.1.0.1)
 ==44318==    by 0xF3F35F7: libssh2_session_init_ex (in /usr/lib/libssh2.so.1.0.1)
 ==44318==    by 0xFED9927: ??? (in /builddir/build/BUILDROOT/curl-7.27.0-3.fc18.ppc/usr/lib/libcurl.so.4.2.0)
 ==44318==    by 0xFEB6BA3: ??? (in /builddir/build/BUILDROOT/curl-7.27.0-3.fc18.ppc/usr/lib/libcurl.so.4.2.0)
 ==44318==    by 0xFEB6F27: ??? (in /builddir/build/BUILDROOT/curl-7.27.0-3.fc18.ppc/usr/lib/libcurl.so.4.2.0)
 ==44318==    by 0xFEB6FF3: ??? (in /builddir/build/BUILDROOT/curl-7.27.0-3.fc18.ppc/usr/lib/libcurl.so.4.2.0)
 ==44318==    by 0xFEC95FF: ??? (in /builddir/build/BUILDROOT/curl-7.27.0-3.fc18.ppc/usr/lib/libcurl.so.4.2.0)
 ==44318==    by 0xFECA427: ??? (in /builddir/build/BUILDROOT/curl-7.27.0-3.fc18.ppc/usr/lib/libcurl.so.4.2.0)
 ==44318==    by 0xFECA6D7: curl_multi_socket_action (in /builddir/build/BUILDROOT/curl-7.27.0-3.fc18.ppc/usr/lib/libcurl.so.4.2.0)
 ==44318==    by 0x10000AEB: notifyCurl (lib582.c:205)
 ==44318==    by 0x10001AF7: test (lib582.c:336)
 ==44318==    by 0xFC014B3: generic_start_main.isra.0 (in /usr/lib/libc-2.16.so)
 ==44318==    by 0xFC0166F: (below main) (in /usr/lib/libc-2.16.so)
 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.
=== End of file valgrind582
Comment 5 Mark Wielaard 2012-10-08 12:03:02 EDT
Simple reproducer:

# cat testppc.c 
#include <openssl/evp.h>

int
main (int argc, char **argv)
{
  OpenSSL_add_all_algorithms();
  // Do nothing
  EVP_cleanup();
  return 0;
}

# gcc -m32 -lssl -lcrypto -o testppc testppc.c 

# valgrind ./testppc
==27547== Memcheck, a memory error detector
==27547== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==27547== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==27547== Command: ./testppc
==27547== 
 op name: And64
 op type is (I64,I64) -> I64
arg tys are (I32,I64)

IR SANITY CHECK FAILURE

IRSB {
   t0:I32   t1:I32   t2:I32   t3:I32   t4:F64   t5:F64   t6:I32   t7:I64
   t8:I32   t9:I32   t10:I32   t11:I32   t12:I32   t13:I32   t14:I32   t15:I32
   t16:I32   t17:I32   t18:I32   t19:I32   t20: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(0xFCDD860, 4, 0) ------
   PUT(1156) = 0xFCDD864:I32
   ------ IMark(0xFCDD430, 4, 0) ------
   PUT(1152) = 0xFCDD430:I32
   t9 = GET:I32(1184)
   t8 = And32(t9,0x3:I32)
   t5 = GET:F64(144)
   t7 = ReinterpF64asI64(t5)
   t4 = I64StoF64(Xor32(t8,And32(Shl32(t8,0x1:I8),0x2:I32)),t7)
   PUT(144) = t4
   ------ IMark(0xFCDD434, 4, 0) ------
   PUT(1152) = 0xFCDD434:I32
   t10 = GET:I32(0)
   t12 = GET:I32(0)
   t11 = And64(Mux0X(And8(0x20:I8,0x1F:I8),t10,Or32(Shl32(t10,And8(0x20:I8,0x1F:I8)),Shr32(t10,Sub8(0x20:I8,And8(0x20:I8,0x1F:I8))))),0xFFFFFFFF:I64)
   PUT(0) = t11
   ------ IMark(0xFCDD438, 4, 0) ------
   PUT(1152) = 0xFCDD438:I32
   t18 = 0xFFFFFFFF:I32
   t15 = t18
   t19 = 0x1:I32
   t16 = t19
   t14 = And32(t16,t15)
   t17 = And32(GET:I32(1156),0xFFFFFFFC:I32)
   if (CmpEQ32(t14,0x0:I32)) goto {Boring} 0xFCDD43C:I32
   goto {Return} t17
}

IN STATEMENT:

t11 = And64(Mux0X(And8(0x20:I8,0x1F:I8),t10,Or32(Shl32(t10,And8(0x20:I8,0x1F:I8)),Shr32(t10,Sub8(0x20:I8,And8(0x20:I8,0x1F:I8))))),0xFFFFFFFF:I64)

ERROR = Iex.Binop: arg tys don't match op tys
... additional details precede BB printout



vex: the `impossible' happened:
   sanityCheckFail: exiting due to bad IR
vex storage: T total 69105992 bytes allocated
vex storage: P total 144 bytes allocated

valgrind: the 'impossible' happened:
   LibVEX called failure_exit().
==27547==    at 0x38053D68: report_and_quit (m_libcassert.c:210)
==27547==    by 0x38053F8F: vgPlain_core_panic_at (m_libcassert.c:294)
==27547==    by 0x38053FC3: vgPlain_core_panic (m_libcassert.c:304)
==27547==    by 0x3807056B: failure_exit (m_translate.c:700)
==27547==    by 0x38107AEF: vpanic (main_util.c:226)
==27547==    by 0x3810F72B: sanityCheckFail (ir_defs.c:2881)
==27547==    by 0x3811249B: tcExpr (ir_defs.c:3185)
==27547==    by 0x381136A3: sanityCheckIRSB (ir_defs.c:3288)
==27547==    by 0x38105F97: LibVEX_Translate (main_main.c:561)
==27547==    by 0x38072BB3: vgPlain_translate (m_translate.c:1544)
==27547==    by 0x380A2FEB: vgPlain_scheduler (scheduler.c:901)
==27547==    by 0x380B7C13: run_a_thread_NORETURN (syswrap-linux.c:98)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==27547==    at 0xFCDD860: OPENSSL_cpuid_setup (in /usr/lib/libcrypto.so.1.0.1c)
==27547==    by 0xFD64FF3: OPENSSL_add_all_algorithms_noconf (in /usr/lib/libcrypto.so.1.0.1c)
==27547==    by 0x10000687: main (in /root/testppc)


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.
Comment 6 Mark Wielaard 2012-10-08 12:57:11 EDT
With yum install openssl-debuginfo.ppc we see:

Thread 1: status = VgTs_Runnable
==28481==    at 0xFCDD860: OPENSSL_cpuid_setup (ppccap.c:96)
==28481==    by 0xFD64FF3: OPENSSL_add_all_algorithms_noconf (c_all.c:82)
==28481==    by 0x10000687: main (in /root/testppc)

Which is /usr/src/debug/openssl-1.0.1c/crypto/ppccap.c:

        if (sizeof(size_t)==4)
                {
                if (sigsetjmp(ill_jmp,1) == 0)
                        {
line 96 ===>            OPENSSL_ppc64_probe();
                        OPENSSL_ppccap_P |= PPC_FPU64;
                        }
                }

And ppc64_probe is defined in /usr/src/debug/openssl-1.0.1c/crypto/ppccpuid.s as:

.globl  OPENSSL_ppc64_probe
.type   OPENSSL_ppc64_probe,@function
.align  4
OPENSSL_ppc64_probe:
        fcfid   1,1
        rldicl  0,0,32,32
        blr
.long   0
.byte   0,12,0x14,0,0,0,0,0
Comment 7 Mark Wielaard 2012-10-17 15:37:27 EDT
There is a nice analysis of this issue in upstream bugzilla:
https://bugs.kde.org/show_bug.cgi?id=308573
Comment 8 Mark Wielaard 2012-10-17 15:59:56 EDT
See also this discussion in the openssl bug tracker about the probing method used: https://rt.openssl.org/Ticket/Display.html?id=2897&user=guest&pass=guest
Comment 9 Jakub Jelinek 2012-10-17 16:09:46 EDT
I think the question is what the hw really does with the instruction in 32-bit mode.  Does it take 32-bit register, zero extend, do the rotation in 64-bit and truncate to 32-bit?  Or does it take the whole 64-bit register (what is the content of the upper bits?).  If the former, it isn't hard for the 64-bit only dis_rot_int instructions to do mode64 ? mkexpr(rS) : unop(Iop_32Uto64, mkexpr(rS))
as argument to ROTL etc., and finally at the end do unop(Iop_64to32, ...) to truncate it back.
Comment 10 Maynard Johnson 2012-10-17 16:49:18 EDT
My team member, Carl Love, and I have been investigating this issue, mostly from the Valgrind perspective since we have responsibility for supporting Valgrind on the ppc64 architecture.  While we realized that Valgrind was misbehaving in this circumstance and needed fixing, we also thought there might be an issue with how openssl was using (or possibly mis-using) a certain instruction that is from the 64-bit category.  This bug occurs only when the programs involved are compiled as 32-bit.  We opened bug #865124 to address the possibility of an openssl bug, but that bug has now been closed as NOTABUG. As noted in the closing comment, a workaround for this valgrind issue (i.e., choking on the rldicl instruction) is to set the OPENSSL_ppccap environment variable to 0 prior running the application under valgrind's control.

We are working on a patch to fix Valgrind so that it will not die when encountering rldicl (and other 64-bit cateogry instructions) when in 32-bit mode.  When this patch is accepted upstream, we'll update this bug.
Comment 11 Mark Wielaard 2012-11-05 09:20:08 EST
Backported patches for upstream bugs KDE#308573 and KDE#309425 to valgrind rawhide package. When valgrind-3.8.1-5 hits the ppc build roots could you try enabling valgrind in the curl package again and do a new build to see if everything now works as expected?
Comment 12 Karsten Hopp 2013-01-20 15:37:02 EST
confirmed that a curl build with valgrind enabled works now
Comment 13 Fedora Update System 2013-02-28 10:28:32 EST
valgrind-3.8.1-9.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/valgrind-3.8.1-9.fc18
Comment 14 Fedora Update System 2013-03-10 21:20:04 EDT
valgrind-3.8.1-9.fc18 has been pushed to the Fedora 18 stable repository.  If problems still persist, please make note of it in this bug report.

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