Re: [Valgrind-users] Crash when running WebKit built with CLANG under Valgrind
Thanks for your reply. It sounds like this is an issue that others are experiencing as well (per the email from Nikolas Zimmerman). It seems to work better with Xcode 3.2, but since WebKit has moved to Xcode 4.x, I think we'll need to use that in order to setup some performance bots. Here is some additional output that contains the intercepts before/after the error messages I'm seeing - maybe it will help. I'm still concerned that since the WebKit test runner is crashing, the output from that point forward may be affected. 16:07:41.586 22660 16:07:41.586 22660 SYSCALL[22708,1](mach: 31) UNHANDLED mach_msg [id 10002, to com.apple.CoreServices.coreservicesd, reply 0xa203] -- [async] ... 16:07:41.586 22660 SYSCALL[22708,1](mach: 31) ... [async] -- Success(0x0:0x0) --22708:0:syswrap- sync_mappings(after, mach_msg_receive (unhandled), 0) 16:07:41.586 22660 --22708:0:syswrap- added region 0x00..0x001000 at mach_msg_receive (unhandled) (after) 16:07:41.586 22660 16:07:41.586 22660 SYSCALL[22708,1](mach: 31) bootstrap_look_up(com.apple.system.logger) -- [async] ... 16:07:41.586 22660 SYSCALL[22708,1](mach: 31) ... [async] -- Success(0x0:0x0) got port unnamed-0xC403; 16:07:41.586 22660 com.apple.system.logger 16:07:41.586 22660 SYSCALL[22708,1](unix: 24) sys_getuid ( )[sync] -- Success(0x0:0x1f5) 16:07:41.586 22660 SYSCALL[22708,1](unix: 47) sys_getgid ( )[sync] -- Success(0x0:0x14) 16:07:41.586 22660 SYSCALL[22708,1](mach: 31) UNHANDLED mach_msg [id 78945670, to com.apple.system.notification_center, reply 0xa203] -- [async] ... 16:07:41.586 22660 SYSCALL[22708,1](mach: 31) ... [async] -- Success(0x0:0x0) --22708:0:syswrap- sync_mappings(after, mach_msg_receive (unhandled), 0) 16:07:41.586 22660 16:07:41.586 22660 SYSCALL[22708,1](mach: 31) UNHANDLED mach_msg [id 78945669, to com.apple.system.notification_center, reply 0xa203] -- [async] ... 16:07:41.586 22660 SYSCALL[22708,1](mach: 31) ... [async] -- Success(0x0:0x0) --22708:0:syswrap- sync_mappings(after, mach_msg_receive (unhandled), 0) 16:07:41.586 22660 16:07:41.586 22660 SYSCALL[22708,1](unix: 25) sys_geteuid ( )[sync] -- Success(0x0:0x1f5) 16:07:41.587 22660 SYSCALL[22708,1](mach: 31) UNHANDLED mach_msg [id 78945669, to com.apple.system.notification_center, reply 0xa203] -- [async] ... 16:07:41.587 22660 SYSCALL[22708,1](mach: 31) ... [async] -- Success(0x0:0x0) --22708:0:syswrap- sync_mappings(after, mach_msg_receive (unhandled), 0) 16:07:41.587 22660 16:07:41.587 22660 SYSCALL[22708,1](mach: 31) UNHANDLED mach_msg [id 78945681, to com.apple.system.notification_center, reply 0xa203] -- [async] ... 16:07:41.587 22660 SYSCALL[22708,1](mach: 31) ... [async] -- Success(0x0:0x0) --22708:0:syswrap- sync_mappings(after, mach_msg_receive (unhandled), 0) 16:07:41.587 22660 16:07:41.587 22660 SYSCALL[22708,1](mach: 31) UNHANDLED mach_msg [id 78945681, to com.apple.system.notification_center, reply 0xa203] -- [async] ... 16:07:41.587 22660 SYSCALL[22708,1](mach: 31) ... [async] -- Success(0x0:0x0) --22708:0:syswrap- sync_mappings(after, mach_msg_receive (unhandled), 0) 16:07:41.587 22660 16:07:41.587 22660 SYSCALL[22708,1](unix:202) __sysctl ( 0x7fff5fbf92f8, 2, 0x7fff5fbf930f, 0x7fff5fbf92f0, 0x0, 0 ) mib: [ 1 10 ][sync] -- Success(0x0:0x0) 16:07:41.587 22660 SYSCALL[22708,1](unix: 24) sys_getuid ( )[sync] -- Success(0x0:0x1f5) 16:07:41.587 22660 SYSCALL[22708,1](unix: 47) sys_getgid ( )[sync] -- Success(0x0:0x14) 16:07:41.587 22660 SYSCALL[22708,1](mach: 31) mach_vm_allocate (mach_task_self(), at 0x0, size 226, flags 0x1) -- [async] ... 16:07:41.587 22660 SYSCALL[22708,1](mach: 31) ... [async] -- Success(0x0:0x0) allocated at 0xfdca000 16:07:41.587 22660 SYSCALL[22708,1](mach: 31) kill ool mem 0xFDCA000..0xfdca0e2; UNHANDLED mach_msg [id 118, to com.apple.system.logger, reply 0x0] -- [async] ... 16:07:41.587 22660 SYSCALL[22708,1](mach: 31) ... [async] -- Success(0x0:0x0) --22708:0:syswrap- sync_mappings(after, mach_msg_receive (unhandled), 0) 16:07:41.587 22660 16:07:41.587 22660 SYSCALL[22708,1](unix: 48) sigprocmask ( 3, 0x7fff5fbfa1c4, 0x0 ) -- [pre-success] Success(0x0:0x0) 16:07:41.587 22660 SYSCALL[22708,1](unix:329) UNKNOWN __pthread_sigmask is unsupported. This warning will not be repeated. 16:07:41.587 22660-- [pre-success] Success(0x0:0x0) 16:07:41.587 22660 SYSCALL[22708,1](unix:328) __pthread_kill ( 3847, 6 )[sync] -- Success(0x0:0x0) 16:07:41.587 22660 SYSCALL[22708,1](unix:423) __semwait_signal(wait semaphore-0xA503, signal NULL, 1, 1, 0s:1000ns) -- [async] ... 16:07:41.587 22660 SYSCALL[22708,1](unix:423) ... [async] -- Failure(0x3c) 16:07:41.587 22660 SYSCALL[22708,1](unix: 46) sigaction ( 6, 0x7fff5fbfa168, 0x0 ) -- [pre-success] Success(0x0:0x0) 16:07:41.587 22660 SYSCALL[22708,1](unix: 48) sigprocmask ( 3, 0x7fff5fbfa194, 0x0 ) -- [pre-success] Success(0x0:0x0) 16:07:41.588 22660 SYSCALL[22708,1](unix:329) -- [pre-success] Success(0x0:0x0)
[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] 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
