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 0x100000F33: 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
