Bug 193295 - devel/valgrind: Doesn't decode instruction(s) when libunwind is used
Summary: devel/valgrind: Doesn't decode instruction(s) when libunwind is used
Status: Closed Feedback Timeout
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: freebsd-ports-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-03 22:17 UTC by Adrian Chadd
Modified: 2017-03-04 14:33 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Chadd freebsd_committer freebsd_triage 2014-09-03 22:17:20 UTC
This happens when debugging an application (libuinet) with libunwind:

UINET multiprocessor subsystem configured with 1 CPUs
vex amd64->IR: unhandled instruction bytes: 0x66 0x8C 0x8F 0xB8 0x0 0x0 0x0 0x66
vex amd64->IR:   REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0
vex amd64->IR:   VEX=0 VEX.L=0 VEX.nVVVV=0x0 ESC=NONE
vex amd64->IR:   PFX.66=1 PFX.F2=0 PFX.F3=0
==9536== valgrind: Unrecognised instruction at address 0x14cf67c.
==9536==    at 0x14CF67C: _Ux86_64_getcontext (in /usr/local/lib/libunwind.so.8)
==9536==    by 0x4A01C3: uhi_get_stacktrace (uinet_host_interface.c:1213)
==9536==    by 0x422154: stack_save (uinet_subr_stack.c:22)
==9536==    by 0x49C033: witness_checkorder (subr_witness.c:2818)
==9536==    by 0x41E646: _rw_wlock (uinet_kern_rwlock.c:105)
==9536==    by 0x457DD9: vnet_if_init (if.c:406)
==9536==    by 0x41AD44: mi_startup (uinet_init_main.c:301)
==9536==    by 0x41A727: uinet_init (uinet_init.c:149)
==9536==    by 0x405D61: norse_libuinet_intercept_setup (norse_intercept_libuinet.c:1330)
==9536==    by 0x405322: main (blockd_libuinet.c:574)
==9536== Your program just tried to execute an instruction that Valgrind
==9536== did not recognise.  There are two possible reasons for this.
==9536== 1. Your program has a bug and erroneously jumped to a non-code
==9536==    location.  If you are running Memcheck and you just saw a
==9536==    warning about a bad jump, it's probably your program's fault.
==9536== 2. The instruction is legitimate but Valgrind doesn't handle it,
==9536==    i.e. it's Valgrind's fault.  If you think this is the case or
==9536==    you are not sure, please let us know and we'll try to fix it.
==9536== Either way, Valgrind will now raise a SIGILL signal which will
==9536== probably kill your program.
==9536== 
==9536== Process terminating with default action of signal 4 (SIGILL): dumping core
==9536==  Illegal opcode at address 0x14CF67C
==9536==    at 0x14CF67C: _Ux86_64_getcontext (in /usr/local/lib/libunwind.so.8)
==9536==    by 0x4A01C3: uhi_get_stacktrace (uinet_host_interface.c:1213)
==9536==    by 0x422154: stack_save (uinet_subr_stack.c:22)
==9536==    by 0x49C033: witness_checkorder (subr_witness.c:2818)
==9536==    by 0x41E646: _rw_wlock (uinet_kern_rwlock.c:105)
==9536==    by 0x457DD9: vnet_if_init (if.c:406)
==9536==    by 0x41AD44: mi_startup (uinet_init_main.c:301)
==9536==    by 0x41A727: uinet_init (uinet_init.c:149)
==9536==    by 0x405D61: norse_libuinet_intercept_setup (norse_intercept_libuinet.c:1330)
==9536==    by 0x405322: main (blockd_libuinet.c:574)
==9536== 
==9536== HEAP SUMMARY:
==9536==     in use at exit: 31,172,630 bytes in 797 blocks
==9536==   total heap usage: 1,139 allocs, 342 frees, 31,176,862 bytes allocated
==9536== 
==9536== LEAK SUMMARY:
==9536==    definitely lost: 206 bytes in 3 blocks
==9536==    indirectly lost: 0 bytes in 0 blocks
==9536==      possibly lost: 66,856 bytes in 31 blocks
==9536==    still reachable: 31,105,568 bytes in 763 blocks
==9536==         suppressed: 0 bytes in 0 blocks
==9536== Rerun with --leak-check=full to see details of leaked memory
==9536== 
==9536== For counts of detected and suppressed errors, rerun with: -v
==9536== Use --track-origins=yes to see where uninitialised values come from
==9536== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Killed
Comment 1 John Marino freebsd_committer freebsd_triage 2014-09-04 17:27:13 UTC
over to maintainer
Comment 2 Mark Linimon freebsd_committer freebsd_triage 2014-11-23 08:08:12 UTC
maintainership was reset.