[Valgrind-users] configure reporting incorrect primary build arch
I am attempting to build Valgrind locally and notice that the output from running configure is: Maximum build arch: amd64 Primary build arch: amd64 Secondary build arch: x86 Build OS: darwin Primary build target: AMD64_DARWIN Secondary build target: X86_DARWIN Platform variant: vanilla Primary -DVGPV string: -DVGPV_amd64_darwin_vanilla=1 Default supp files: exp-sgcheck.supp xfree-3.supp xfree-4.supp darwin10-drd.supp darwin11.supp I'm running on a MacBook Pro with an Intel i7 CPU (running OS X 10.7.4), so I'm not sure why the primary build arch is amd64. Does anyone know why I'm seeing this? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] configure reporting incorrect primary build arch
On Thu, 2012-07-12 at 14:42 -0700, Jacob Goldstein wrote: Primary build arch: amd64 Secondary build arch: x86 I'm running on a MacBook Pro with an Intel i7 CPU (running OS X 10.7.4), so I'm not sure why the primary build arch is amd64. amd64 indicates it is the intel architecture in 64 bits. If I am not wrong, it is amd that defined the extension of the x86 to 64 bits, and so that is one (the?) reason to call it amd64. See also http://www.valgrind.org/info/platforms.html So, no problem. Philippe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] Crash when running WebKit built with CLANG under Valgrind
Hello, I have been attempting to build and run WebKit LayoutTests under Valgrind, without much success. WebKit is being built with Xcode. It works as expected with Xcode 3.x, which uses GCC, but not with Xcode 4.x, which uses CLANG. A simple program works fine with each, but when I build WebKit itself, I get a crash anytime it is built with CLANG (while everything else is identical). Does anyone have an idea what could be causing this? This may or may not be related, but my primary build arch, as reported by configure, appears to be incorrect: Maximum build arch: amd64 Primary build arch: amd64 Secondary build arch: x86 Build OS: darwin Primary build target: AMD64_DARWIN Secondary build target: X86_DARWIN Platform variant: vanilla Primary -DVGPV string: -DVGPV_amd64_darwin_vanilla=1 Default supp files: exp-sgcheck.supp xfree-3.supp xfree-4.supp darwin10-drd.supp darwin11.supp I'm running on a MacBook Pro with an Intel i7 CPU, so I'm not sure why the primary build arch is amd64. The crash when running a WebKit test under Valgrind looks like the following (some output has been removed): Output - ==21326== Memcheck, a memory error detector ==21326== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==21326== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==21326== Command: /Users/jacobg/WebKit/WebKitBuild/Debug/DumpRenderTree - ==21326== UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated. vex amd64-IR: unhandled instruction bytes: 0xF 0xB 0x55 0x48 0x89 0xE5 0x41 0x56 vex amd64-IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64-IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=0F vex amd64-IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==21326== valgrind: Unrecognised instruction at address 0x9167b8c. ==21326==at 0x9167B8C: __abort (in /usr/lib/system/libsystem_c.dylib) ==21326==by 0x9167AAA: abort (in /usr/lib/system/libsystem_c.dylib) … ==21326== Your program just tried to execute an instruction that Valgrind ==21326== did not recognise. There are two possible reasons for this. ==21326== 1. Your program has a bug and erroneously jumped to a non-code ==21326==location. If you are running Memcheck and you just saw a ==21326==warning about a bad jump, it's probably your program's fault. ==21326== 2. The instruction is legitimate but Valgrind doesn't handle it, ==21326==i.e. it's Valgrind's fault. If you think this is the case or ==21326==you are not sure, please let us know and we'll try to fix it. ==21326== Either way, Valgrind will now raise a SIGILL signal which will ==21326== probably kill your program. ==21326== ==21326== Process terminating with default action of signal 4 (SIGILL) ==21326== Illegal opcode at address 0x9167B8C … -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] configure reporting incorrect primary build arch
Ah, ok, thanks for the clarification. On 7/12/12 2:52 PM, Philippe Waroquiers philippe.waroqui...@skynet.be wrote: On Thu, 2012-07-12 at 14:42 -0700, Jacob Goldstein wrote: Primary build arch: amd64 Secondary build arch: x86 I'm running on a MacBook Pro with an Intel i7 CPU (running OS X 10.7.4), so I'm not sure why the primary build arch is amd64. amd64 indicates it is the intel architecture in 64 bits. If I am not wrong, it is amd that defined the extension of the x86 to 64 bits, and so that is one (the?) reason to call it amd64. See also http://www.valgrind.org/info/platforms.html So, no problem. Philippe -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] configure reporting incorrect primary build arch
Maximum build arch: amd64 Primary build arch: amd64 Secondary build arch: x86 Build OS: darwin Primary build target: AMD64_DARWIN Secondary build target: X86_DARWIN Platform variant: vanilla Primary -DVGPV string: -DVGPV_amd64_darwin_vanilla=1 Default supp files: exp-sgcheck.supp xfree-3.supp xfree-4.supp darwin10-drd.supp darwin11.supp I'm running on a MacBook Pro with an Intel i7 CPU (running OS X 10.7.4), so I'm not sure why the primary build arch is amd64. Does anyone know why I'm seeing this? Total red herring. amd64 is merely the name used to denote 64 bit x86. Works fine on Intels too. J -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Strange warning for invalid read of size 8 in memcpy
On Wed, Jul 11, 2012 at 10:13 PM, Tanmay Mohapatra tanma...@hotmail.com wrote: Thanks Pat. Here's the output of otool -v -t check Is this what is required? Do let me know if I need to disassemble in some other way. Looks like the offending code is in a shared library (?) Maybe try gdb ./check, and then x/10i 0x7FE00BAC? (Or x/50i 0x7FE00B10 or something? Unfortunately we do not know the actual function being called, so it is hard to get the context. Disassembling at 0x7FE00BAC will show us the instruction but not the context; disassembling from somewhat earlier will show us the context but might be out of sync with the actual instruction stream) - Pat We need to see the actual code that is being executed. In particular, you haven't shown the code which surrounds 0x7FE00BAC from your initial report: ==57528== Invalid read of size 8 ==57528== at 0x7FE00BAC: ??? ==57528== by 0x10E4D: __inline_memcpy_chk (in ./check) Please produce a disassembly of __inline_memcpy_chk that surrounds address 0x10E4D. Please produce a disassembly of the routine that __inline_memcpy_chk calls (probably surrounding 0x7FE00BAC). -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Crash when running WebKit built with CLANG under Valgrind
This doesn't really help you, but ... The crash when running a WebKit test under Valgrind looks like the following (some output has been removed): Output - ==21326== Memcheck, a memory error detector ==21326== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==21326== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==21326== Command: /Users/jacobg/WebKit/WebKitBuild/Debug/DumpRenderTree - ==21326== UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated. vex amd64-IR: unhandled instruction bytes: 0xF 0xB 0x55 0x48 0F 0B is the official Intel undefined instruction, so V is correct to whack your app on the head with SIGILL at this point. The messages are admittedly confusing though. Why the program SIGILLd though, I don't know. One important question is: UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated. Does that also get reported for the XCode 3.x built version, or only w/ XCode 4? J -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Crash when running WebKit built with CLANG under Valgrind
I'm running on a MacBook Pro with an Intel i7 CPU, so I'm not sure why the primary build arch is amd64. Because the best [5-character] name of the 64-bit x86 architecture is amd64. AMD beat the pants off Intel in that round of the architecture wars. The crash when running a WebKit test under Valgrind looks like the following (some output has been removed): Output - ==21326== Memcheck, a memory error detector ==21326== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==21326== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==21326== Command: /Users/jacobg/WebKit/WebKitBuild/Debug/DumpRenderTree - ==21326== UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated. vex amd64-IR: unhandled instruction bytes: 0xF 0xB 0x55 0x48 0x89 0xE5 0x41 0x56 ==21326== valgrind: Unrecognised instruction at address 0x9167b8c. 0xF 0xB is 'ud2', the official two-byte undefined opcode. The app has given up, and 'ud2' is an OS-independent way to guarantee an abort. (It's an infuriating bug that valgrind pretends not to know about 'ud2'.) The real error happened some time ago. To help find it, please re-run: valgrind --trace-system-calls=yes .../DumpRenderTree -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] Crash when running WebKit built with CLANG under Valgrind
Julian and John - thanks very much for your replies, I really appreciate your help. --trace-syscalls=yes worked. I got a lot of SYSCALLs. Let me provide a little more background in case this helps shed some light on the situation. I'm running on two different machines: 1) MacBook Pro / Intel i7 / OS X 10.7.4 / Xcode 4.3.1 (which uses LLVM/CLANG) 2) iMac / Intel Core 2 Duo / OS X 10.6.8 / Xcode 3.2 (which uses GCC) I'm running valgrind-3.8.0.SVN that I built locally. I get different results on each machine. I'm running a single WebKit test via a script that invokes a test runner called DumpRenderTree. When I run on either machine without Valgrind, everything runs as expected and the test passes. When I run on the MacBook Pro (with WebKit and DumpRenderTree built using LLVM/CLANG), I see DumpRenderTree crash right before valgrind outputs anything at all (see the output at the end of this message). This concerns me. The DumpRenderTree crash could be corrupting everything that comes after it. When I run on the iMac, I do not see DumpRenderTree crash, the test appears to run and Valgrind outputs a bunch of errors, such as: Invalid read of size 8 ... Conditional jump or move depends on uninitialized value(s) ... Use of uninitialized value of size 8 ... etcŠ And ultimately the test finishes and passes. There are obviously a couple of variables here - the main two I'm looking at are the version of Mac OS X, and the version of Xcode. Xcode made a big change from 3.x to 4.x by moving from GCC to LLVM/CLANG, so that is currently my main suspect. Unfortunately, recent versions of Xcode are not supported on OS X 10.6, and vice versa. I do think I can find a version of Xcode 4.x that will run on OS X 10.6 - which should help determine if Xcode really is the problem and not the version of OS X. Is there a policy on this list about attaching files? I could attach the full output from each run, but they would be around ~200K total when zipped. Here is the first 100 lines once the test appears to have started running when executed on the MacBook Pro --- output --- Š 16:06:56.456 22660 16:06:56.456 22660 Sharding tests ... 16:06:56.456 22660 Running 1 DumpRenderTree over 1 shard 16:06:56.456 22660 Starting 1 worker ... 16:06:56.558 22660 Starting testing ... 16:06:56.558 22660 worker/0 starting 16:07:01.343 22660 looking for crash log for DumpRenderTree:22708 16:07:41.443 22660 worker/0 fast/regions/content-webkit-from-flow-parsing.html crashed, stack trace: 16:07:41.445 22660 ==22708== Memcheck, a memory error detector 16:07:41.445 22660 ==22708== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. 16:07:41.445 22660 ==22708== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info 16:07:41.445 22660 ==22708== Command: /Users/jacobg/WebKit/WebKitBuild/Debug/DumpRenderTree - 16:07:41.445 22660 ==22708== 16:07:41.445 22660 SYSCALL[22708,1](mach: 28) mach_task_self()[sync] -- Success(0x0:0x1107) task 0x1107 16:07:41.445 22660 SYSCALL[22708,1](mdep: 3) thread_fast_set_cthread_self ( 0x7fff5fc39830 ) -- [pre-success] Success(0x0:0x60) 16:07:41.446 22660 SYSCALL[22708,1](mach: 26) mach_reply_port()[sync] -- Success(0x0:0xe07) reply port reply-0xE07 16:07:41.446 22660 SYSCALL[22708,1](unix:327) issetugid ( )[sync] -- Success(0x0:0x0) 16:07:41.446 22660 SYSCALL[22708,?](UNKNOWN: 0) syscall(unix:169, ...); please stand by... 16:07:41.446 22660 SYSCALL[22708,1](unix:169) csops ( 0, 0x0, 0x7fff5fbff7cc, 4 )[sync] -- Success(0x0:0x0) 16:07:41.446 22660 SYSCALL[22708,1](unix:338) stat64 ( 0x7fff5fc3b5b8(/usr/local/lib/valgrind/vgpreload_core-amd64-darwin.so), 0x7fff5fbfe8e0 )[sync] -- Success(0x0:0x0) 16:07:41.446 22660 SYSCALL[22708,1](unix: 5) sys_open ( 0x7fff5fc3b5b8(/usr/local/lib/valgrind/vgpreload_core-amd64-darwin.so), 0 ) -- [async] ... 16:07:41.446 22660 SYSCALL[22708,1](unix: 5) ... [async] -- Success(0x0:0x3) 16:07:41.446 22660 SYSCALL[22708,1](unix:153) sys_pread64 ( 3, 0x7fff5fbfd868, 4096, 0 ) -- [async] ... 16:07:41.446 22660 SYSCALL[22708,1](unix:153) ... [async] -- Success(0x0:0x1000) 16:07:41.446 22660 SYSCALL[22708,1](mach: 26) mach_reply_port()[sync] -- Success(0x0:0xd07) reply port reply-0xD07 16:07:41.446 22660 SYSCALL[22708,1](mach: 31) mach_vm_allocate (mach_task_self(), at 0x0, size 40960, flags 0x1) -- [async] ... 16:07:41.446 22660 SYSCALL[22708,1](mach: 31) ... [async] -- Success(0x0:0x0) allocated at 0x1000 16:07:41.447 22660 SYSCALL[22708,1](unix:197) mmap ( 0x1000, 28672, 5, 18, 3, 0 )[sync] -- Success(0x0:0x1000) 16:07:41.447 22660 SYSCALL[22708,1](unix:197) mmap ( 0x8000, 4096, 3, 18, 3, 28672 )[sync] -- Success(0x0:0x8000) 16:07:41.447 22660 SYSCALL[22708,1](unix:197) mmap ( 0x9000, 4468, 1, 18, 3, 32768 )[sync] -- Success(0x0:0x9000) 16:07:41.447 22660 SYSCALL[22708,1](unix: 6) sys_close ( 3 )[sync] -- Success(0x0:0x0) 16:07:41.447 22660 SYSCALL[22708,1](unix:338) stat64 (
Re: [Valgrind-users] Crash when running WebKit built with CLANG under Valgrind
I'm running on two different machines: 1) MacBook Pro / Intel i7 / OS X 10.7.4 / Xcode 4.3.1 (which uses LLVM/CLANG) 2) iMac / Intel Core 2 Duo / OS X 10.6.8 / Xcode 3.2 (which uses GCC) I'm running valgrind-3.8.0.SVN that I built locally. I get different results on each machine. Please read [Valgrind-users] from about a week ago; the thread: Poster: Tanmay Mohapatra tanma...@hotmail.com Subject: Strange warning for invalid read of size 8 in memcpy Xcode 3.2 has some strange memcpy which triggers a complaint from memcheck. So far, we have not been unable to get a disassembly. Can you post the code that surrounds the actual instruction which draws the complaint? Something like the output from (gdb) x/50i 0x7FE00BAC - 0x40 if the pc *at* the complaint was 0x7FE00BAC ? Xcode 3.2 also evades valgrind's REDIR machinery. Run with valgrind -v and notice how REDIR works in XCode 4.3.y (I have 4.3.2 under Darwin 11.4.0) but not in XCode 3.2. When --trace-syscalls=yes, then the important pieces are: 1) the 20 intercepts which surround (10 before, 10 after): UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated. 2) the 20 intercepts just prior to: vex amd64-IR: unhandled instruction bytes: 0xF 0xB 0x55 0x48 0x89 0xE5 0x41 0x56 -- -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
