|
From: Istvan C. <Ist...@lo...> - 2012-02-09 12:02:41
|
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 ==71202== valgrind: Unrecognised instruction at address 0x3945c0b. ==71202== at 0x3945C0B: aes_encrypt_key_hw (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x39439E0: aesedp_setup (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x393DBE3: cbc_start (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x39405BB: CCCryptorCreateFromDataWithMode (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x394078D: CCCryptorCreateFromData (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x393FDFC: CCCryptorCreate (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x3940DC6: CCCrypt (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x4A8463: -[NSPersistentUIManager init] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x4A8350: __PersistentUIManager_block_invoke_1 (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x1A4936A: _NSFaultInObject (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation) ==71202== by 0x4E807E: -[NSWindow(NSPersistentUISupport) _invalidateRestorableStateOfContents] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x5F8066: -[NSWindow _commonInitFrame:styleMask:backing:defer:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x5F753A: -[NSWindow _initContent:styleMask:backing:defer:contentView:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x5F6F0A: -[NSWindow initWithContentRect:styleMask:backing:defer:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x67512E: -[NSWindowTemplate nibInstantiate] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x48E550: -[NSIBObjectData instantiateObject:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x48D7AC: -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x48409E: loadNib (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x48359B: +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x4834B6: +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x4833F9: +[NSBundle(NSNibLoading) loadNibNamed:owner:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x6F69B2: NSApplicationMain (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x100001791: main (in ./tmp) ==71202== Your program just tried to execute an instruction that Valgrind ==71202== did not recognise. There are two possible reasons for this. ==71202== 1. Your program has a bug and erroneously jumped to a non-code ==71202== location. If you are running Memcheck and you just saw a ==71202== warning about a bad jump, it's probably your program's fault. ==71202== 2. The instruction is legitimate but Valgrind doesn't handle it, ==71202== i.e. it's Valgrind's fault. If you think this is the case or ==71202== you are not sure, please let us know and we'll try to fix it. ==71202== Either way, Valgrind will now raise a SIGILL signal which will ==71202== probably kill your program. ==71202== ==71202== Process terminating with default action of signal 4 (SIGILL) ==71202== Illegal opcode at address 0x3945C0B ==71202== at 0x3945C0B: aes_encrypt_key_hw (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x39439E0: aesedp_setup (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x393DBE3: cbc_start (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x39405BB: CCCryptorCreateFromDataWithMode (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x394078D: CCCryptorCreateFromData (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x393FDFC: CCCryptorCreate (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x3940DC6: CCCrypt (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x4A8463: -[NSPersistentUIManager init] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x4A8350: __PersistentUIManager_block_invoke_1 (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x1A4936A: _NSFaultInObject (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation) ==71202== by 0x4E807E: -[NSWindow(NSPersistentUISupport) _invalidateRestorableStateOfContents] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x5F8066: -[NSWindow _commonInitFrame:styleMask:backing:defer:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) I am using Valgrind 3.7.0 but also tried the main trunk (3.8.0) without any success. Any help is greatly appreciated. Regards, Istvan Csanady |
|
From: Istvan C. <Ist...@lo...> - 2012-02-09 12:03:23
|
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 ==71202== valgrind: Unrecognised instruction at address 0x3945c0b. ==71202== at 0x3945C0B: aes_encrypt_key_hw (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x39439E0: aesedp_setup (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x393DBE3: cbc_start (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x39405BB: CCCryptorCreateFromDataWithMode (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x394078D: CCCryptorCreateFromData (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x393FDFC: CCCryptorCreate (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x3940DC6: CCCrypt (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x4A8463: -[NSPersistentUIManager init] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x4A8350: __PersistentUIManager_block_invoke_1 (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x1A4936A: _NSFaultInObject (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation) ==71202== by 0x4E807E: -[NSWindow(NSPersistentUISupport) _invalidateRestorableStateOfContents] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x5F8066: -[NSWindow _commonInitFrame:styleMask:backing:defer:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x5F753A: -[NSWindow _initContent:styleMask:backing:defer:contentView:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x5F6F0A: -[NSWindow initWithContentRect:styleMask:backing:defer:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x67512E: -[NSWindowTemplate nibInstantiate] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x48E550: -[NSIBObjectData instantiateObject:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x48D7AC: -[NSIBObjectData nibInstantiateWithOwner:topLevelObjects:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x48409E: loadNib (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x48359B: +[NSBundle(NSNibLoading) _loadNibFile:nameTable:withZone:ownerBundle:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x4834B6: +[NSBundle(NSNibLoading) loadNibFile:externalNameTable:withZone:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x4833F9: +[NSBundle(NSNibLoading) loadNibNamed:owner:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x6F69B2: NSApplicationMain (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x100001791: main (in ./tmp) ==71202== Your program just tried to execute an instruction that Valgrind ==71202== did not recognise. There are two possible reasons for this. ==71202== 1. Your program has a bug and erroneously jumped to a non-code ==71202== location. If you are running Memcheck and you just saw a ==71202== warning about a bad jump, it's probably your program's fault. ==71202== 2. The instruction is legitimate but Valgrind doesn't handle it, ==71202== i.e. it's Valgrind's fault. If you think this is the case or ==71202== you are not sure, please let us know and we'll try to fix it. ==71202== Either way, Valgrind will now raise a SIGILL signal which will ==71202== probably kill your program. ==71202== ==71202== Process terminating with default action of signal 4 (SIGILL) ==71202== Illegal opcode at address 0x3945C0B ==71202== at 0x3945C0B: aes_encrypt_key_hw (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x39439E0: aesedp_setup (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x393DBE3: cbc_start (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x39405BB: CCCryptorCreateFromDataWithMode (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x394078D: CCCryptorCreateFromData (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x393FDFC: CCCryptorCreate (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x3940DC6: CCCrypt (in /usr/lib/system/libcommonCrypto.dylib) ==71202== by 0x4A8463: -[NSPersistentUIManager init] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x4A8350: __PersistentUIManager_block_invoke_1 (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x1A4936A: _NSFaultInObject (in /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation) ==71202== by 0x4E807E: -[NSWindow(NSPersistentUISupport) _invalidateRestorableStateOfContents] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) ==71202== by 0x5F8066: -[NSWindow _commonInitFrame:styleMask:backing:defer:] (in /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit) I am using Valgrind 3.7.0 but also tried the main trunk (3.8.0) without any success. Any help is greatly appreciated. Regards, Istvan Csanady |
|
From: John R. <jr...@bi...> - 2012-02-09 15:54:01
|
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. -- |
|
From: Eliot M. <mo...@cs...> - 2012-02-09 12:15:56
|
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 |
|
From: Eliot M. <mo...@cs...> - 2012-02-09 13:00:33
|
I was wrong :-( ... 0x66 0x0F 0x3A 0xDF appears to be AESKEYGENASSIST. Someone else will have to address that (if at all). Sorry ... Eliot |
|
From: Nick O. <ni...@as...> - 2012-02-09 13:34:38
|
Ah, that would be great news! I'd love to have valgrind work with OSX-apps. Looking forward to it! On 9 feb. 2012, at 13:15:45, Eliot Moss wrote: > 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users |
|
From: Tom H. <to...@co...> - 2012-02-09 13:40:45
|
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 (to...@co...) http://compton.nu/ |
|
From: Philippe W. <phi...@sk...> - 2012-02-13 21:30:46
|
On Thu, 2012-02-09 at 13:40 +0000, 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 |
|
From: Alexander P. <gl...@go...> - 2012-02-09 13:47:59
|
On Thu, Feb 9, 2012 at 5:00 PM, Eliot Moss <mo...@cs...> 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 $0x02000000, %%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. |
|
From: Jan W. <jan...@gm...> - 2012-02-10 07:00:14
|
> 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 |
|
From: Philippe W. <phi...@sk...> - 2012-02-09 19:37:01
|
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 2000000 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) |
|
From: Julian S. <js...@ac...> - 2012-02-09 20:15:21
|
> 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
|