Re: [Valgrind-users] can't start any application on OS X 10.7.3
On Sat, Apr 28, 2012 at 1:39 PM, Matt Broadstone mbroa...@gmail.com wrote: On Fri, Apr 27, 2012 at 6:42 PM, Julian Seward jsew...@acm.org wrote: On Friday, April 27, 2012, Matt Broadstone wrote: On Fri, Apr 27, 2012 at 10:58 AM, Julian Seward jsew...@acm.org wrote: * change the line MACX_(__NR___pthread_sigmask, __pthread_sigmask), to read MACX_(__NR___pthread_sigmask, __pthread_sigmask), Oops. I mean, change it to MACXY(__NR___pthread_sigmask, __pthread_sigmask), J Hmm, well I added that (I had to provide an empty POST for __pthread_sigmask to get it working, not sure if thats kosher, it looked like it should be), but we're still failing. My analysis was wrong. It's unrelated to __pthread_sigmask; the program has already decided to abort before that point. Seems like a permissions problem of some kind (setuid problem, I'd guess). Putting sudo in front of my valgrind invokation for textedit makes it run successfully. Does the same trick work for you? J Yep, this works for me. Matt Bad news. This seems to work fine for TextEdit.app, but not anything else I'm trying. Interestingly, the problem with the other applications is the exact same __abort call which for some reason is not being triggered when I run a sudo valgrind path to TextEdit.app. My new test case is: sudo valgrind /Applications/Firefox.app/Contents/MacOS/firefox-bin which fails in an illegal opcode in __abort again. Matt -- 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] can't start any application on OS X 10.7.3
On Fri, Apr 27, 2012 at 6:42 PM, Julian Seward jsew...@acm.org wrote: On Friday, April 27, 2012, Matt Broadstone wrote: On Fri, Apr 27, 2012 at 10:58 AM, Julian Seward jsew...@acm.org wrote: * change the line MACX_(__NR___pthread_sigmask, __pthread_sigmask), to read MACX_(__NR___pthread_sigmask, __pthread_sigmask), Oops. I mean, change it to MACXY(__NR___pthread_sigmask, __pthread_sigmask), J Hmm, well I added that (I had to provide an empty POST for __pthread_sigmask to get it working, not sure if thats kosher, it looked like it should be), but we're still failing. My analysis was wrong. It's unrelated to __pthread_sigmask; the program has already decided to abort before that point. Seems like a permissions problem of some kind (setuid problem, I'd guess). Putting sudo in front of my valgrind invokation for textedit makes it run successfully. Does the same trick work for you? J Yep, this works for me. Matt -- 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] can't start any application on OS X 10.7.3
On Thu, Apr 26, 2012 at 5:08 PM, Julian Seward jsew...@acm.org wrote: Okay, I was able to get that working. Here is the result of disassembling that instruction: 0x03a36b8c __abort+225: ud2a Yeah, so as expected it's died on ud2a, as the vex amd64-IR: unhandled instruction bytes: 0xF 0xB line implies -- 0F 0B is ud2a. The real question is, why did the program jump to abort() in the first place. That will have to wait till I or someone else finds the time to investigate locally. One thing you could do is run with --trace-flags=1000. This prints symbol names as code is visited for the first time. Grep this lot to see if there are any references to misaligned or stack (or some combination thereof) in it. That has been a known trouble spot in the past. Also, maybe post the last 100 or so lines of it here. Overall, though, your best bet is to file a bug report with a precise description of how to reproduce the problem. Bug reports sent by email tend to become lost or forgotten about. You can file a report by following the directions at http://valgrind.org/support/bug_reports.html J You said you had SVN working on OSX this past weekend right? Are you running 10.7.3? Anyway, misaligned and stack don't seem to be showing up in this output, but it seems like the abort is happening after something related to syslog here? Here is the last couple hundred lines (including the unhandled instruction message): SB 21391 (evchecks 10199503) [tid 1] 0x3a64b06 _asl_msg_string_length_aux+566 /usr/lib/system/libsystem_c.dylib+0x6fb06 SB 21392 (evchecks 10199503) [tid 1] 0x3a64b3e _asl_msg_string_length_aux+622 /usr/lib/system/libsystem_c.dylib+0x6fb3e SB 21393 (evchecks 10199503) [tid 1] 0x3a6421a _asl_msg_fetch_internal /usr/lib/system/libsystem_c.dylib+0x6f21a SB 21394 (evchecks 10199503) [tid 1] 0x3a6423f _asl_msg_fetch_internal+37 /usr/lib/system/libsystem_c.dylib+0x6f23f SB 21395 (evchecks 10199503) [tid 1] 0x3a64b70 _asl_msg_string_length_aux+672 /usr/lib/system/libsystem_c.dylib+0x6fb70 SB 21396 (evchecks 10199503) [tid 1] 0x3a64cda _asl_msg_string_length_aux+1034 /usr/lib/system/libsystem_c.dylib+0x6fcda SB 21397 (evchecks 10199503) [tid 1] 0x3a70a21 _asl_send_message+1622 /usr/lib/system/libsystem_c.dylib+0x7ba21 SB 21398 (evchecks 10199503) [tid 1] 0x3a70a2f _asl_send_message+1636 /usr/lib/system/libsystem_c.dylib+0x7ba2f SB 21399 (evchecks 10199503) [tid 1] 0x3a9d802 __clzsi2+5922 /usr/lib/system/libsystem_c.dylib+0xa8802 SB 21400 (evchecks 10200614) [tid 1] 0x3a70a5c _asl_send_message+1681 /usr/lib/system/libsystem_c.dylib+0x7ba5c SB 21401 (evchecks 10200614) [tid 1] 0x3a70a64 _asl_send_message+1689 /usr/lib/system/libsystem_c.dylib+0x7ba64 SB 21402 (evchecks 10200627) [tid 1] 0xe0e5 memset+133 /usr/local/lib/valgrind/vgpreload_memcheck-amd64-darwin.so+0x30e5 SB 21403 (evchecks 10200627) [tid 1] 0xe0f0 memset+144 /usr/local/lib/valgrind/vgpreload_memcheck-amd64-darwin.so+0x30f0 SB 21404 (evchecks 10200627) [tid 1] 0x3a70a75 _asl_send_message+1706 /usr/lib/system/libsystem_c.dylib+0x7ba75 SB 21405 (evchecks 10200656) [tid 1] 0x3a3ac07 __vfprintf+13732 /usr/lib/system/libsystem_c.dylib+0x45c07 SB 21406 (evchecks 10200656) [tid 1] 0x3a3ac9c __vfprintf+13881 /usr/lib/system/libsystem_c.dylib+0x45c9c SB 21407 (evchecks 10200674) [tid 1] 0x3a6cebb __sfvwrite+476 /usr/lib/system/libsystem_c.dylib+0x77ebb SB 21408 (evchecks 10200680) [tid 1] 0x3a70a95 _asl_send_message+1738 /usr/lib/system/libsystem_c.dylib+0x7ba95 SB 21409 (evchecks 10200680) [tid 1] 0x3a65393 _asl_msg_to_string_buffer_aux+47 /usr/lib/system/libsystem_c.dylib+0x70393 SB 21410 (evchecks 10200680) [tid 1] 0x3a6539a _asl_msg_to_string_buffer_aux+54 /usr/lib/system/libsystem_c.dylib+0x7039a SB 21411 (evchecks 10200680) [tid 1] 0x3a65433 _asl_msg_to_string_buffer_aux+207 /usr/lib/system/libsystem_c.dylib+0x70433 SB 21412 (evchecks 10200680) [tid 1] 0x3a65438 _asl_msg_to_string_buffer_aux+212 /usr/lib/system/libsystem_c.dylib+0x70438 SB 21413 (evchecks 10200680) [tid 1] 0x3a65449 _asl_msg_to_string_buffer_aux+229 /usr/lib/system/libsystem_c.dylib+0x70449 SB 21414 (evchecks 10200680) [tid 1] 0x3a650d9 _msg_to_string_buffer_helper+80 /usr/lib/system/libsystem_c.dylib+0x700d9 SB 21415 (evchecks 10200680) [tid 1] 0x3a650e9 _msg_to_string_buffer_helper+96 /usr/lib/system/libsystem_c.dylib+0x700e9 SB 21416 (evchecks 10200680) [tid 1] 0x3a6521f _msg_to_string_buffer_helper+406 /usr/lib/system/libsystem_c.dylib+0x7021f SB 21417 (evchecks 10200680) [tid 1] 0x3a64d2f _asl_append_string+38 /usr/lib/system/libsystem_c.dylib+0x6fd2f SB 21418 (evchecks 10200680) [tid 1] 0x3a64d38 _asl_append_string+47 /usr/lib/system/libsystem_c.dylib+0x6fd38 SB 21419 (evchecks 10200680) [tid 1] 0x3a64d41 _asl_append_string+56 /usr/lib/system/libsystem_c.dylib+0x6fd41 SB 21420 (evchecks
Re: [Valgrind-users] can't start any application on OS X 10.7.3
I reproduced this with the trunk on 10.7.3 using TextEdit, as you said. It's pretty clear from --trace-flags=1000 output that it happens because the syscall __pthread_sigmask isn't supported, and so returns with failure. This presumably spooks /usr/lib/libsystem_c.dylib and so it calls abort() immediately afterwards. One thing you could try, in syswrap-darwin.c: * change function PRE(__pthread_sigmask) so that its body is identical to that for PRE(sigprocmask) further down the file. * create a function POST(__pthread_sigmask) as a copy of POST(sigprocmask) * change the line MACX_(__NR___pthread_sigmask, __pthread_sigmask), to read MACX_(__NR___pthread_sigmask, __pthread_sigmask), That might help, by making it handle __pthread_sigmask identically to sigprocmask. (Or it might not.) 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] can't start any application on OS X 10.7.3
* change the line MACX_(__NR___pthread_sigmask, __pthread_sigmask), to read MACX_(__NR___pthread_sigmask, __pthread_sigmask), Oops. I mean, change it to MACXY(__NR___pthread_sigmask, __pthread_sigmask), 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] can't start any application on OS X 10.7.3
On Fri, Apr 27, 2012 at 10:58 AM, Julian Seward jsew...@acm.org wrote: * change the line MACX_(__NR___pthread_sigmask, __pthread_sigmask), to read MACX_(__NR___pthread_sigmask, __pthread_sigmask), Oops. I mean, change it to MACXY(__NR___pthread_sigmask, __pthread_sigmask), J Hmm, well I added that (I had to provide an empty POST for __pthread_sigmask to get it working, not sure if thats kosher, it looked like it should be), but we're still failing. Interestingly this message is now output without trace flags: 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 perhaps that's a result of the MACXY addition though. Matt -- 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] can't start any application on OS X 10.7.3
On Friday, April 27, 2012, Matt Broadstone wrote: On Fri, Apr 27, 2012 at 10:58 AM, Julian Seward jsew...@acm.org wrote: * change the line MACX_(__NR___pthread_sigmask, __pthread_sigmask), to read MACX_(__NR___pthread_sigmask, __pthread_sigmask), Oops. I mean, change it to MACXY(__NR___pthread_sigmask, __pthread_sigmask), J Hmm, well I added that (I had to provide an empty POST for __pthread_sigmask to get it working, not sure if thats kosher, it looked like it should be), but we're still failing. My analysis was wrong. It's unrelated to __pthread_sigmask; the program has already decided to abort before that point. Seems like a permissions problem of some kind (setuid problem, I'd guess). Putting sudo in front of my valgrind invokation for textedit makes it run successfully. Does the same trick work for you? 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] can't start any application on OS X 10.7.3
On Thursday, April 26, 2012, John Reiser wrote: It's a *BUG* in valgrind that valgrind does not print the bytes [or words, etc.] of the instruction stream that valgrind does not understand. [This is immediately obvious to *EVERY* user, but so far the developers have been oblivious.] It always prints the bytes of the instruction it can't parse. Without that we'd never be able to make sense of any unhandled insn style bug reports. It seems like you removed them from the initial posting, though. Do you have a line of the form vex amd64-IR: unhandled instruction bytes: 0xC5 0xF8 0x77 0xC3 0xF6 Anyway, I suspect that will merely tell us that abort crapped out on 0x0F 0x0D, which is the official undefined instruction ud2, so that's not useful. We need to know why the program jumped to abort() in the first place. The svn trunk does work on OSX 10.7.3 -- I was working with it at the weekend. Really what is needed is a way to reproduce this failure. 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] can't start any application on OS X 10.7.3
On Thu, 2012-04-26 at 09:29 -0400, Matt Broadstone wrote: As for doing a db-attach, that seems to have failed as well - I never make it to a gdb session. Here is the full output of a db-attach valgrind run on TextEdit.app: ==76980== Attach to debugger ? --- [Return/N/n/Y/y/C/c] Y valgrind: m_debugger.c:238 (ptrace_setregs): Assertion 'Unimplemented functionality' failed. The above assert indicates that --db-attach is not implemented on darwin. You could however try the Valgrind gdbserver, which is supposed to work (at least, I manually tested it on Darwin something like one year ago on a 3.7.0 SVN). You could try to investigate why abort is called by using 2 GDBs to debug: * a native run * a run under Valgrind and see at which point/instruction their executions are diverging. (e.g. put breakpoint in _SCSessionUniverseByUIDAcquireAndLock and then use stepi or similar.). 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] can't start any application on OS X 10.7.3
On Thu, Apr 26, 2012 at 2:06 PM, Philippe Waroquiers philippe.waroqui...@skynet.be wrote: On Thu, 2012-04-26 at 09:29 -0400, Matt Broadstone wrote: As for doing a db-attach, that seems to have failed as well - I never make it to a gdb session. Here is the full output of a db-attach valgrind run on TextEdit.app: ==76980== Attach to debugger ? --- [Return/N/n/Y/y/C/c] Y valgrind: m_debugger.c:238 (ptrace_setregs): Assertion 'Unimplemented functionality' failed. The above assert indicates that --db-attach is not implemented on darwin. You could however try the Valgrind gdbserver, which is supposed to work (at least, I manually tested it on Darwin something like one year ago on a 3.7.0 SVN). You could try to investigate why abort is called by using 2 GDBs to debug: * a native run * a run under Valgrind and see at which point/instruction their executions are diverging. (e.g. put breakpoint in _SCSessionUniverseByUIDAcquireAndLock and then use stepi or similar.). Philippe first I ran: valgrind --vgdb=yes --vgdb-error=0 /Applications/TextEdit.app/Contents/MacOS/TextEdit then I ran: gdb /Applications/TextEdit.app/Contents/MacOS/TextEdit and then: (gdb) target remote | /usr/local/bin/vgdb | /usr/local/bin/vgdb: Undefined error: 0 I was just following the steps in the manual, is there something special I'm missing here? Matt -- 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] can't start any application on OS X 10.7.3
On Thu, 2012-04-26 at 14:17 -0400, Matt Broadstone wrote: and then: (gdb) target remote | /usr/local/bin/vgdb | /usr/local/bin/vgdb: Undefined error: 0 You must have a version of gdb recent enough (I believe = 6.5) otherwise GDB does not understand the | target. Two alternatives: * compile + install a recent GDB (there is a kind of magic security signing which is needed). * alternatively: valgrind --vgdb-error=0 prog # and then in another shell, run: vgdb --port=1234 # in a third shell: gdb prog (gdb) target remote :1234 (NB: with this technique, there is no security: anybody which have access to your system can connect to the vgdb port nr). 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] can't start any application on OS X 10.7.3
On Thu, Apr 26, 2012 at 3:27 PM, Philippe Waroquiers philippe.waroqui...@skynet.be wrote: On Thu, 2012-04-26 at 14:17 -0400, Matt Broadstone wrote: and then: (gdb) target remote | /usr/local/bin/vgdb | /usr/local/bin/vgdb: Undefined error: 0 You must have a version of gdb recent enough (I believe = 6.5) otherwise GDB does not understand the | target. Two alternatives: * compile + install a recent GDB (there is a kind of magic security signing which is needed). * alternatively: valgrind --vgdb-error=0 prog # and then in another shell, run: vgdb --port=1234 # in a third shell: gdb prog (gdb) target remote :1234 (NB: with this technique, there is no security: anybody which have access to your system can connect to the vgdb port nr). Philippe Okay, I was able to get that working. Here is the result of disassembling that instruction: Program received signal SIGILL, Illegal instruction. warning: Error 268435459 getting port names from mach_port_names [Switching to process 4359 thread 0x0] 0x03a36b8c in __abort () (gdb) disas Dump of assembler code for function __abort: 0x03a36aab __abort+0: push %rbp 0x03a36aac __abort+1: mov%rsp,%rbp 0x03a36aaf __abort+4: push %rbx 0x03a36ab0 __abort+5: sub$0x18,%rsp 0x03a36ab4 __abort+9: cmpq $0x0,0x9cf6c(%rip)# 0x3ad3a28 gCRAnnotations+8 0x03a36abc __abort+17:jne0x3a36acc __abort+33 0x03a36abe __abort+19:lea0x6f2b3(%rip),%rax# 0x3aa5d78 __rcsid_37+80 0x03a36ac5 __abort+26:mov%rax,0x9cf5c(%rip)# 0x3ad3a28 gCRAnnotations+8 0x03a36acc __abort+33:movq $0x0,-0x18(%rbp) 0x03a36ad4 __abort+41:movl $0x0,-0xc(%rbp) 0x03a36adb __abort+48:movl $0x,-0x10(%rbp) 0x03a36ae2 __abort+55:mov$0x6,%edi 0x03a36ae7 __abort+60:lea-0x18(%rbp),%rsi 0x03a36aeb __abort+64:xor%edx,%edx 0x03a36aed __abort+66:callq 0x3a97c1c sigaction 0x03a36af2 __abort+71:andb $0xdf,-0x10(%rbp) 0x03a36af6 __abort+75:lea0xa34b3(%rip),%rax# 0x3ad9fb0 __is_threaded 0x03a36afd __abort+82:cmpl $0x0,(%rax) 0x03a36b00 __abort+85:lea-0x10(%rbp),%rbx 0x03a36b04 __abort+89:je 0x3a36b4c __abort+161 0x03a36b06 __abort+91:movl $0x,-0x1c(%rbp) 0x03a36b0d __abort+98:lea-0x1c(%rbp),%rsi 0x03a36b11 __abort+102: mov$0x3,%edi 0x03a36b16 __abort+107: xor%edx,%edx 0x03a36b18 __abort+109: callq 0x3a9c772 dyld_stub_sigprocmask 0x03a36b1d __abort+114: mov$0x1,%edi 0x03a36b22 __abort+119: xor%al,%al 0x03a36b24 __abort+121: callq 0x3a42e3b __pthread_workqueue_setkill 0x03a36b29 __abort+126: mov$0x3,%edi 0x03a36b2e __abort+131: mov%rbx,%rsi 0x03a36b31 __abort+134: xor%edx,%edx 0x03a36b33 __abort+136: callq 0x3a42ca7 pthread_sigmask 0x03a36b38 __abort+141: callq 0x3a97540 pthread_self 0x03a36b3d __abort+146: mov$0x6,%esi 0x03a36b42 __abort+151: mov%rax,%rdi 0x03a36b45 __abort+154: callq 0x3a45773 pthread_kill 0x03a36b4a __abort+159: jmp0x3a36b6c __abort+193 0x03a36b4c __abort+161: mov$0x3,%edi 0x03a36b51 __abort+166: xor%edx,%edx 0x03a36b53 __abort+168: mov%rbx,%rsi 0x03a36b56 __abort+171: callq 0x3a9c772 dyld_stub_sigprocmask 0x03a36b5b __abort+176: callq 0x3a9c4f0 dyld_stub_getpid 0x03a36b60 __abort+181: mov$0x6,%esi 0x03a36b65 __abort+186: mov%eax,%edi 0x03a36b67 __abort+188: callq 0x3a9c54a dyld_stub_kill 0x03a36b6c __abort+193: mov$0x2710,%edi 0x03a36b71 __abort+198: callq 0x3a36c43 usleep$NOCANCEL 0x03a36b76 __abort+203: movl $0xffe7,-0x10(%rbp) 0x03a36b7d __abort+210: mov$0x3,%edi 0x03a36b82 __abort+215: xor%edx,%edx 0x03a36b84 __abort+217: mov%rbx,%rsi 0x03a36b87 __abort+220: callq 0x3a9c772 dyld_stub_sigprocmask 0x03a36b8c __abort+225: ud2a End of assembler dump. (gdb) Matt -- 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/ ___
Re: [Valgrind-users] can't start any application on OS X 10.7.3
Okay, I was able to get that working. Here is the result of disassembling that instruction: 0x03a36b8c __abort+225: ud2a Yeah, so as expected it's died on ud2a, as the vex amd64-IR: unhandled instruction bytes: 0xF 0xB line implies -- 0F 0B is ud2a. The real question is, why did the program jump to abort() in the first place. That will have to wait till I or someone else finds the time to investigate locally. One thing you could do is run with --trace-flags=1000. This prints symbol names as code is visited for the first time. Grep this lot to see if there are any references to misaligned or stack (or some combination thereof) in it. That has been a known trouble spot in the past. Also, maybe post the last 100 or so lines of it here. Overall, though, your best bet is to file a bug report with a precise description of how to reproduce the problem. Bug reports sent by email tend to become lost or forgotten about. You can file a report by following the directions at http://valgrind.org/support/bug_reports.html 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] can't start any application on OS X 10.7.3
On Tue, Apr 24, 2012 at 6:16 PM, Philippe Waroquiers
philippe.waroqui...@skynet.be wrote:
On Tue, 2012-04-24 at 14:06 -0400, Matt Broadstone wrote:
Not sure how to post to this thread having just signed up for the
list, but hopefully this routes correctly..
Hi,
I wanted to confirm that the aes changes in trunk do indeed solve that
unrecognized instruction issue, however,
I am still experiencing immediate termination whenever I use valgrind
with the following output:
==66368== valgrind: Unrecognised instruction at address 0x3a36b8c.
==66368== at 0x3A36B8C: __abort (in /usr/lib/system/libsystem_c.dylib)
==66368== by 0x3A36AAA: abort (in /usr/lib/system/libsystem_c.dylib)
==66368== by 0x3D79431: _SCSessionUniverseByUIDAcquireAndLock (in
The above does not match the symptoms of an aes instruction not
recognised (see e.g. bug 290655).
From the above, I am guessing that _SCSessionUniverseByUIDAcquireAndLock
encounters a problem, and calls abort. Abort might be implemented via
an illegal instruction.
You might verify that by just doing a small executable calling abort
and see if that gives the same behaviour.
Otherwise, disassemble the instructions at 0x3a36b8c.
Philippe
I created a simple program to call abort:
#include stdlib.h
int main(int argc, char **argv)
{
abort();
return 0;
}
and the valgrind output is:
==54377== Memcheck, a memory error detector
==54377== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==54377== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info
==54377== Command: ./test
==54377==
--54377-- ./test:
--54377-- dSYM directory is missing; consider using --dsymutil=yes
==54377==
==54377== Process terminating with default action of signal 6 (SIGABRT)
==54377==at 0x2C182A: __kill (in /usr/lib/system/libsystem_kernel.dylib)
==54377==by 0x10F33: main (in ./test)
==54377==
==54377== HEAP SUMMARY:
==54377== in use at exit: 1,999 bytes in 32 blocks
==54377== total heap usage: 32 allocs, 0 frees, 1,999 bytes allocated
==54377==
==54377== LEAK SUMMARY:
==54377==definitely lost: 0 bytes in 0 blocks
==54377==indirectly lost: 0 bytes in 0 blocks
==54377== possibly lost: 0 bytes in 0 blocks
==54377==still reachable: 1,999 bytes in 32 blocks
==54377== suppressed: 0 bytes in 0 blocks
==54377== Rerun with --leak-check=full to see details of leaked memory
==54377==
==54377== For counts of detected and suppressed errors, rerun with: -v
==54377== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Abort trap: 6
So, that looks like it works. Unfortunately, with trunk valgrind I get
this __abort error running just about any application I've tried it on
(though it seems to be related to anything linked to CarbonCore). I
tried to run gdb on my test program and disassemble the address given
by valgrind, but it claims there is no function at that address? Can
you point me towards how to get you the information you require?
Matt
--
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] can't start any application on OS X 10.7.3
Not sure how to post to this thread having just signed up for the list, but hopefully this routes correctly.. Hi, I wanted to confirm that the aes changes in trunk do indeed solve that unrecognized instruction issue, however, I am still experiencing immediate termination whenever I use valgrind with the following output: ==66368== valgrind: Unrecognised instruction at address 0x3a36b8c. ==66368==at 0x3A36B8C: __abort (in /usr/lib/system/libsystem_c.dylib) ==66368==by 0x3A36AAA: abort (in /usr/lib/system/libsystem_c.dylib) ==66368==by 0x3D79431: _SCSessionUniverseByUIDAcquireAndLock (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore) ==66368==by 0x3D73358: FSNodeStorageGetAndLockCurrentUniverse (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore) ==66368==by 0x3D731C0: FileIDTreeGetAndLockVolumeEntryForDeviceID (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore) ==66368==by 0x3D97E63: FSMount::FSMount(unsigned int, FSMountNumberType, int*, unsigned int const*) (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore) ==66368==by 0x3D97D58: FSMountPrepare (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/CarbonCore.framework/Versions/A/CarbonCore) ==66368==by 0x8D8EDA3: MountInfoPrepare(void***, unsigned int, int, void*, unsigned int const*, __CFURL const*, __CFError**) (in /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal) ==66368==by 0x8D80ADF: parseAttributeBuffer(__CFAllocator const*, unsigned char const*, unsigned char, attrlist const*, void const*, void**, _FileAttributes*, unsigned int*) (in /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal) ==66368==by 0x8D81167: corePropertyProviderPrepareValues(__CFURL const*, __FileCache*, __CFString const* const*, void const**, long, void const*, __CFError**) (in /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal) ==66368==by 0x8D7D737: prepareValuesForBitmap(__CFURL const*, __FileCache*, _FilePropertyBitmap*, __CFError**) (in /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal) ==66368==by 0x8D82778: _FSURLGetCatalogInfo (in /System/Library/PrivateFrameworks/CoreServicesInternal.framework/Versions/A/CoreServicesInternal) ==66368==by 0x44863BA: FSNodePrepareCatalogInfo (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices) ==66368==by 0x44867E9: _LSGetBundleClassForNode (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices) ==66368==by 0x4487304: _LSFindOrRegisterBundleNode (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices) ==66368==by 0x448B420: _LSRegisterSelf (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices) ==66368==by 0x448A301: _LSApplicationCheckIn (in /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/LaunchServices) ==66368==by 0x575BF55: _RegisterApplication (in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices) ==66368==by 0x575A89C: GetCurrentProcess (in /System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks/HIServices.framework/Versions/A/HIServices) ==66368==by 0x235147A: _GetAggregateUIMode (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox) ==66368==by 0x2351433: IsMenuBarVisible (in /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox) ==66368==by 0x97820E: _NSInitializeAppContext (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==66368==by 0x97774A: -[NSApplication init] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==66368==by 0x977371: +[NSApplication sharedApplication] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==66368==by 0xBF88E0: NSApplicationMain (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==66368==by 0x11677: ??? (in /Applications/TextEdit.app/Contents/MacOS/TextEdit) Matt -- 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.
Re: [Valgrind-users] can't start any application on OS X 10.7.3
On Tue, 2012-04-24 at 14:06 -0400, Matt Broadstone wrote: Not sure how to post to this thread having just signed up for the list, but hopefully this routes correctly.. Hi, I wanted to confirm that the aes changes in trunk do indeed solve that unrecognized instruction issue, however, I am still experiencing immediate termination whenever I use valgrind with the following output: ==66368== valgrind: Unrecognised instruction at address 0x3a36b8c. ==66368==at 0x3A36B8C: __abort (in /usr/lib/system/libsystem_c.dylib) ==66368==by 0x3A36AAA: abort (in /usr/lib/system/libsystem_c.dylib) ==66368==by 0x3D79431: _SCSessionUniverseByUIDAcquireAndLock (in The above does not match the symptoms of an aes instruction not recognised (see e.g. bug 290655). From the above, I am guessing that _SCSessionUniverseByUIDAcquireAndLock encounters a problem, and calls abort. Abort might be implemented via an illegal instruction. You might verify that by just doing a small executable calling abort and see if that gives the same behaviour. Otherwise, disassemble the instructions at 0x3a36b8c. 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] can't start any application on OS X 10.7.3
On Thu, 2012-02-09 at 13:40 +, Tom Hughes wrote: On 09/02/12 13:00, Eliot Moss wrote: 0x66 0x0F 0x3A 0xDF appears to be AESKEYGENASSIST. Someone else will have to address that (if at all). There's a bug for that already: https://bugs.kde.org/show_bug.cgi?id=290655 I just attached to the bug a patch on 3.8.0 SVN implementing the 6 AES instructions. Patch includes a test but it would be nice if testing could be done using a real application using AES (e.g. firefox) and report if this is working properly. Thanks Philippe -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] can't start any application on OS X 10.7.3
On 2/9/2012 6:55 AM, Istvan Csanady wrote: Hi All, I am trying to use Valgrind on OS X 10.7.3, and when I try to start a Cocoa application, it always crashes at the following point: vex amd64-IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xDF 0xD1 0x1 0xE8 0x6A That looks like a variant of the PCMPxSTRx instruction. I am working on a patch that will add *some* new cases to that instruction, not previously supported by valgrind, but at a glance this one is different :-( ... I can't look into the manuals now to be certain, but can probably get back within a day. Perhaps someone else can verify it. If this variant is close enough to existing ones, I *might* be able to add it to what I am patching Regards -- Eliot Moss -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] can't start any application on OS X 10.7.3
On 09/02/12 13:00, Eliot Moss wrote: 0x66 0x0F 0x3A 0xDF appears to be AESKEYGENASSIST. Someone else will have to address that (if at all). There's a bug for that already: https://bugs.kde.org/show_bug.cgi?id=290655 Tom -- Tom Hughes (t...@compton.nu) http://compton.nu/ -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] can't start any application on OS X 10.7.3
On Thu, Feb 9, 2012 at 5:00 PM, Eliot Moss m...@cs.umass.edu wrote:
I was wrong :-( ...
0x66 0x0F 0x3A 0xDF appears to be AESKEYGENASSIST.
Someone else will have to address that (if at all).
Sorry ... Eliot
There used to be a bug about incorrect declaration of AESKEYGENASSIST:
https://bugs.kde.org/show_bug.cgi?id=249991
Can you please try this code:
#include stdio.h
int main() {
unsigned int result = -1;
asm volatile(
mov $0x1, %%eax\n
cpuid\n
mov $0x0200, %%eax\n
and %%eax, %%ecx\n
mov %%ecx, %0\n: =r(result));
printf(%x\n, result);
return 0;
}
under Valgrind on your machine?
If it returns 0, it means that the code you're running is incorrectly
assuming AES support on the CPU (this is still a reason to fix
AESKEYGENASSIST)
Otherwise cpuid is broken under Valgrind.
--
Virtualization Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] can't start any application on OS X 10.7.3
On 02/09/2012 03:50 AM, Istvan Csanady wrote: vex amd64-IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xDF 0xD1 0x1 0xE8 0x6A Any help is greatly appreciated. Such as, RTFM? It's even a FAQ!! Begin at http://valgrind.org . Notice Documentation in the sidebar. Click on FAQ. http://valgrind.org/docs/manual/faq.html#faq.msgdeath Search for 'unhandled'. That instruction is aeskeygenassist $0x1,%xmm1,%xmm2 which anyone can determine by creating a file foo.S containing the one line .byte 0x66,0xF,0x3A,0xDF,0xD1,0x1,0xE8,0x6A then assembling and disassembling: $ gcc -c foo.S $ gdb foo.o (gdb) x/i 0 0x0: aeskeygenassist $0x1,%xmm1,%xmm2 Valgrind does not [yet] support the aes* instructions. Recommendation: trade-in your fancy new Mac for a better machine (an __older__ box) that lacks the AES instructions. Older boxes are *better* because they run the software that _you_ need to run! Or, try SnowLeopard (Mac OS X 10.6.*) instead of Lion (Mac OS X 10.7.*). Or, wait until valgrind supports AES. -- -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] can't start any application on OS X 10.7.3
On Thu, 2012-02-09 at 17:47 +0400, Alexander Potapenko wrote: under Valgrind on your machine? If it returns 0, it means that the code you're running is incorrectly assuming AES support on the CPU (this is still a reason to fix AESKEYGENASSIST) Otherwise cpuid is broken under Valgrind. Testing on an Xeon X5670 (which supports AES instructions), we see that a native run of Alexander's code tells AES is supported, but the synthetic cpu emulated by Valgrind indicates AES is not supported (which is the case). See below. So, it looks like the application you are trying to run does not verify at runtime if AES is supported or not (e.g. if this is checked at installation time and different executable is installed depending on this install check, then no luck (until Valgrind supports the AES instructions). FYI: I am busy working on implementing the AES instructions. Not very advanced yet, but I guess it should arrive in the coming weeks. Philippe ./cpu_aes 200 philippe@gcc20:~/valgrind/aes_trials$ ~/valgrind/trunk_untouched/vg-in-place ./cpu_aes ==14424== Memcheck, a memory error detector ==14424== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==14424== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==14424== Command: ./cpu_aes ==14424== 0 ==14424== ==14424== HEAP SUMMARY: ==14424== in use at exit: 0 bytes in 0 blocks ==14424== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==14424== ==14424== All heap blocks were freed -- no leaks are possible ==14424== ==14424== For counts of detected and suppressed errors, rerun with: -v ==14424== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4) -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] can't start any application on OS X 10.7.3
at runtime if AES is supported or not (e.g. if this is checked at installation time and different executable is installed depending on this install check, then no luck (until Valgrind supports the AES instructions). Yeah, I agree with that analysis. The failing instruction is in a system library ==71202== valgrind: Unrecognised instruction at address 0x3945c0b. ==71202==at 0x3945C0B: aes_encrypt_key_hw (in /usr/lib/system/libcommonCrypto.dylib) so it seems reasonably that the library was customised at install time, and can simply assume it won't get run on any other CPU. So we can't avoid solving this problem merely by adjusting the simulated CPUID output bits. J -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] can't start any application on OS X 10.7.3
FYI: I am busy working on implementing the AES instructions. Not very advanced yet, but I guess it should arrive in the coming weeks. Philippe, it is great that you are working on this, would be very useful for the project I am working on. Unfortunately I am not qualified to help, but hope your implementation goes well! Best Regards Jan -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
