Bug 515768

Created attachment 356385 [details]
patch from upstream

Just to clarify comment 0 since I didn't copy-and-paste all the lines, the full instruction is:

  40044c:       66 66 66 66 66 66 2e    nopw   %cs:0x0(%rax,%rax,1)
  400453:       0f 1f 84 00 00 00 00                               
  40045a:       00

The "Illegal Instruction" bug still exists with patched 3.2.1-7 version. Here is the output:

valgrind ./ibyhogtw.linux_64.tsk -pldir libpurple_install

/ -t -m 3882 -l ./ibyhogtw.log

==12646== Memcheck, a memory error detector.

==12646== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.

==12646== Using LibVEX rev 1658, a library for dynamic binary translation.

==12646== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.

==12646== Using valgrind-3.2.1, a dynamic binary instrumentation framework.

==12646== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.

==12646== For more details, rerun with: -v

==12646== 



(process:12646): GLib-CRITICAL **: g_main_loop_is_running: assertion `loop != NULL' failed

PLUGINS: /bb/mbig/mbig2617/libpurple_install/

vex amd64->IR: unhandled instruction bytes: 0xF0 0xF 0xB0 0x4D

==12646== valgrind: Unrecognised instruction at address 0x487398.

==12646== Your program just tried to execute an instruction that Valgrind

==12646== did not recognise.  There are two possible reasons for this.

==12646== 1. Your program has a bug and erroneously jumped to a non-code

==12646==    location.  If you are running Memcheck and you just saw a

==12646==    warning about a bad jump, it's probably your program's fault.

==12646== 2. The instruction is legitimate but Valgrind doesn't handle it,

==12646==    i.e. it's Valgrind's fault.  If you think this is the case or

==12646==    you are not sure, please let us know and we'll try to fix it.

==12646== Either way, Valgrind will now raise a SIGILL signal which will

==12646== probably kill your program.

==12646== 

==12646== Process terminating with default action of signal 4 (SIGILL): dumping core

==12646==  Illegal opcode at address 0x487398

==12646==    at 0x487398: BLP::bcemt_RecursiveMutexImpl<BLP::bces_Platform::PosixThreads>::lock() (in /n

et/nnap4211-s/vol/mbig6/mbig2617/openib/ibyhogtw/ibyhogtw.linux_64.tsk)

==12646==    by 0x483379: BLP::bael_FixedSizeRecordBuffer::removeAll() (in /net/nnap4211-s/vol/mbig6/mbig2617/op

enib/ibyhogtw/ibyhogtw.linux_64.tsk)

==12646==    by 0x4717F2: BLP::bael_Logger::~bael_Logger() (in /net/nnap4211-s/vol/mbig6/mbig2617/openib/ibyhogt

w/ibyhogtw.linux_64.tsk)

==12646==    by 0x471A85: BLP::bael_LoggerManager::~bael_LoggerManager() (in /net/nnap4211-s/vol/mbig6/mbig2617/

openib/ibyhogtw/ibyhogtw.linux_64.tsk)

==12646==    by 0x406943: ibyhogtw::LoggerManager::~LoggerManager() (bslma_deleterhelper.h:120)

==12646==    by 0x434FD3: main (ibyhogtw.m.cpp:254)

==12646== 

==12646== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 32 from 1)

==12646== malloc/free: in use at exit: 305,933 bytes in 3,582 blocks.

==12646== malloc/free: 9,624 allocs, 6,042 frees, 2,450,975 bytes allocated.

==12646== For counts of detected errors, rerun with: -v

==12646== searching for pointers to 3,582 not-freed blocks.

==12646== checked 719,752 bytes.

==12646== 

==12646== LEAK SUMMARY:

==12646==    definitely lost: 84,331 bytes in 836 blocks.

==12646==      possibly lost: 6,808 bytes in 65 blocks.

==12646==    still reachable: 214,794 bytes in 2,681 blocks.

==12646==         suppressed: 0 bytes in 0 blocks.

==12646== Use --leak-check=full to see details of leaked memory.

Illegal instruction


PLEASE NOTE: The same binary runs fine under valgrind 3.4.1.

The RHEL5.5 beta version of valgrind fixes the issue reported earlier.

linxdev8 # rpm -q valgrind
valgrind-3.5.0-1.el5.x86_64

linxdev8 # valgrind --tool=memcheck bces_atomicutilimpl_amd64.t.dbg_exc_mt_64 1
==23179== Memcheck, a memory error detector
==23179== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==23179== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==23179== Command: bces_atomicutilimpl_amd64.t.dbg_exc_mt_64 1
==23179==
TEST bces_atomicutilimpl_amd64.t.cpp CASE 1
==23179==
==23179== HEAP SUMMARY:
==23179==     in use at exit: 4,290 bytes in 181 blocks
==23179==   total heap usage: 486 allocs, 305 frees, 5,411 bytes allocated
==23179==
==23179== LEAK SUMMARY:
==23179==    definitely lost: 0 bytes in 0 blocks
==23179==    indirectly lost: 0 bytes in 0 blocks
==23179==      possibly lost: 0 bytes in 0 blocks
==23179==    still reachable: 4,290 bytes in 181 blocks
==23179==         suppressed: 0 bytes in 0 blocks
==23179== Rerun with --leak-check=full to see details of leaked memory
==23179==
==23179== For counts of detected and suppressed errors, rerun with: -v
==23179== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2010-0272.html