> 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

Reply via email to