> Okay, I was able to get that working. Here is the result of > disassembling that instruction: > > 0x0000000003a36b8c <__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=10000000. 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