unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Danny Wilson
I am trying to find a memory leak in a large C++ program which utilizes multiple shared libraries.

Unfortunately, valgrind fails with "unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45"

It says the illegal instruction is inside std::tr1::__detail, inside a standard library...

Is there anything I can do about this?  I've posted the valgrind output and platform information below.

Thanks!


VALGRIND OUTPUT
==18984== Memcheck, a memory error detector
==18984== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==18984== Using Valgrind-3.12.0 and LibVEX; rerun with -h for copyright info
==18984== Command: ./DvMain
==18984==
vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
==18984== valgrind: Unrecognised instruction at address 0x406ae5a.
==18984==    at 0x406AE5A: std::tr1::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned int) const (hashtable_policy.h:460)
==18984==    by 0x4353724: std::tr1::_Hashtable<DvDbDataBaseObject*, DvDbDataBaseObject*, std::allocator<DvDbDataBaseObject*>, std::_Identity<DvDbDataBaseObject*>, equalp<DvDbDataBaseObject>, DvDbDataBaseObject::Hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, true, true>::_Hashtable(unsigned int, DvDbDataBaseObject::Hash const&, std::tr1::__detail::_Mod_range_hashing const&, std::tr1::__detail::_Default_ranged_hash const&, equalp<DvDbDataBaseObject> const&, std::_Identity<DvDbDataBaseObject*> const&, std::allocator<DvDbDataBaseObject*> const&) (hashtable:590)
==18984==    by 0x4352D81: std::tr1::__unordered_set<DvDbDataBaseObject*, DvDbDataBaseObject::Hash, equalp<DvDbDataBaseObject>, std::allocator<DvDbDataBaseObject*>, false>::__unordered_set(unsigned int, DvDbDataBaseObject::Hash const&, equalp<DvDbDataBaseObject> const&, std::allocator<DvDbDataBaseObject*> const&) (unordered_set:70)
==18984==    by 0x4352734: std::tr1::unordered_set<DvDbDataBaseObject*, DvDbDataBaseObject::Hash, equalp<DvDbDataBaseObject>, std::allocator<DvDbDataBaseObject*> >::unordered_set(unsigned int, DvDbDataBaseObject::Hash const&, equalp<DvDbDataBaseObject> const&, std::allocator<DvDbDataBaseObject*> const&) (unordered_set:198)
==18984==    by 0x584F672: __static_initialization_and_destruction_0(int, int) (DvDbIPSystemOpModeSettings.cpp:22)
==18984==    by 0x584F70E: global constructors keyed to DvDbIPSystemOpModeSettings.cpp (DvDbIPSystemOpModeSettings.cpp:68)
==18984==    by 0x584FCFC: ??? (in /usr/local/dvstation/lib/libdvdbip.so.6.0-27)
==18984==    by 0x57EE103: ??? (in /usr/local/dvstation/lib/libdvdbip.so.6.0-27)
==18984==    by 0x49E26FFE: _dl_init (in /lib/ld-2.12.so)
==18984==    by 0x49E1888E: ??? (in /lib/ld-2.12.so)
==18984== Your program just tried to execute an instruction that Valgrind
==18984== did not recognise.  There are two possible reasons for this.
==18984== 1. Your program has a bug and erroneously jumped to a non-code
==18984==    location.  If you are running Memcheck and you just saw a
==18984==    warning about a bad jump, it's probably your program's fault.
==18984== 2. The instruction is legitimate but Valgrind doesn't handle it,
==18984==    i.e. it's Valgrind's fault.  If you think this is the case or
==18984==    you are not sure, please let us know and we'll try to fix it.
==18984== Either way, Valgrind will now raise a SIGILL signal which will
==18984== probably kill your program.
==18984==
==18984== Process terminating with default action of signal 4 (SIGILL)
==18984==  Illegal opcode at address 0x406AE5A
==18984==    at 0x406AE5A: std::tr1::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned int) const (hashtable_policy.h:460)
==18984==    by 0x4353724: std::tr1::_Hashtable<DvDbDataBaseObject*, DvDbDataBaseObject*, std::allocator<DvDbDataBaseObject*>, std::_Identity<DvDbDataBaseObject*>, equalp<DvDbDataBaseObject>, DvDbDataBaseObject::Hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, true, true>::_Hashtable(unsigned int, DvDbDataBaseObject::Hash const&, std::tr1::__detail::_Mod_range_hashing const&, std::tr1::__detail::_Default_ranged_hash const&, equalp<DvDbDataBaseObject> const&, std::_Identity<DvDbDataBaseObject*> const&, std::allocator<DvDbDataBaseObject*> const&) (hashtable:590)
==18984==    by 0x4352D81: std::tr1::__unordered_set<DvDbDataBaseObject*, DvDbDataBaseObject::Hash, equalp<DvDbDataBaseObject>, std::allocator<DvDbDataBaseObject*>, false>::__unordered_set(unsigned int, DvDbDataBaseObject::Hash const&, equalp<DvDbDataBaseObject> const&, std::allocator<DvDbDataBaseObject*> const&) (unordered_set:70)
==18984==    by 0x4352734: std::tr1::unordered_set<DvDbDataBaseObject*, DvDbDataBaseObject::Hash, equalp<DvDbDataBaseObject>, std::allocator<DvDbDataBaseObject*> >::unordered_set(unsigned int, DvDbDataBaseObject::Hash const&, equalp<DvDbDataBaseObject> const&, std::allocator<DvDbDataBaseObject*> const&) (unordered_set:198)
==18984==    by 0x584F672: __static_initialization_and_destruction_0(int, int) (DvDbIPSystemOpModeSettings.cpp:22)
==18984==    by 0x584F70E: global constructors keyed to DvDbIPSystemOpModeSettings.cpp (DvDbIPSystemOpModeSettings.cpp:68)
==18984==    by 0x584FCFC: ??? (in /usr/local/dvstation/lib/libdvdbip.so.6.0-27)
==18984==    by 0x57EE103: ??? (in /usr/local/dvstation/lib/libdvdbip.so.6.0-27)
==18984==    by 0x49E26FFE: _dl_init (in /lib/ld-2.12.so)
==18984==    by 0x49E1888E: ??? (in /lib/ld-2.12.so)
==18984==
==18984== HEAP SUMMARY:
==18984==     in use at exit: 49,009 bytes in 864 blocks
==18984==   total heap usage: 922 allocs, 58 frees, 118,931 bytes allocated
==18984==
==18984== LEAK SUMMARY:
==18984==    definitely lost: 0 bytes in 0 blocks
==18984==    indirectly lost: 0 bytes in 0 blocks
==18984==      possibly lost: 0 bytes in 0 blocks
==18984==    still reachable: 49,009 bytes in 864 blocks
==18984==                       of which reachable via heuristic:
==18984==                         stdstring          : 948 bytes in 48 blocks
==18984==         suppressed: 0 bytes in 0 blocks
==18984== Rerun with --leak-check=full to see details of leaked memory
==18984==
==18984== For counts of detected and suppressed errors, rerun with: -v
==18984== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 156 from 8)
Illegal instruction


PLATFORM INFORMATION
$ uname -a
Linux 3.10.80-1.el6.elrepo.i686 #1 SMP Sun Jun 7 08:15:14 EDT 2015 i686 i686 i386 GNU/Linux

$ cat /etc/redhat-release
CentOS release 6.6 (Final)

$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz
stepping : 3
microcode : 0x1a
cpu MHz : 3600.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 0
initial apicid : 0
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips : 7199.60
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz
stepping : 3
microcode : 0x1a
cpu MHz : 3600.000
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 2
initial apicid : 2
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips : 7199.60
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz
stepping : 3
microcode : 0x1a
cpu MHz : 3600.421
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 0
cpu cores : 2
apicid : 1
initial apicid : 1
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips : 7199.60
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 60
model name : Intel(R) Core(TM) i3-4160 CPU @ 3.60GHz
stepping : 3
microcode : 0x1a
cpu MHz : 3600.703
cache size : 3072 KB
physical id : 0
siblings : 4
core id : 1
cpu cores : 2
apicid : 3
initial apicid : 3
fdiv_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 fma cx16 xtpr pdcm pcid sse4_1 sse4_2 movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm arat xsaveopt pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid
bogomips : 7199.60
clflush size : 64
cache_alignment : 64
address sizes : 39 bits physical, 48 bits virtual
power management:

------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Jeffrey Walton
On Fri, Nov 25, 2016 at 9:38 PM, Danny Wilson <[hidden email]> wrote:

> I am trying to find a memory leak in a large C++ program which utilizes
> multiple shared libraries.
>
> Unfortunately, valgrind fails with "unhandled instruction bytes: 0xC5 0xF9
> 0x6E 0x45"
>
> It says the illegal instruction is inside std::tr1::__detail, inside a
> standard library...
>
> Is there anything I can do about this?  I've posted the valgrind output and
> platform information below.

Looks very similar to https://bugs.kde.org/show_bug.cgi?id=301967 .

Jeff

------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Tom Hughes-2
On 26/11/16 15:36, Jeffrey Walton wrote:

> On Fri, Nov 25, 2016 at 9:38 PM, Danny Wilson <[hidden email]> wrote:
>> I am trying to find a memory leak in a large C++ program which utilizes
>> multiple shared libraries.
>>
>> Unfortunately, valgrind fails with "unhandled instruction bytes: 0xC5 0xF9
>> 0x6E 0x45"
>>
>> It says the illegal instruction is inside std::tr1::__detail, inside a
>> standard library...
>>
>> Is there anything I can do about this?  I've posted the valgrind output and
>> platform information below.
>
> Looks very similar to https://bugs.kde.org/show_bug.cgi?id=301967 .

Yes that looks like an AVX instruction and those are not supported by
valgrind in 32 bit code - try 64 bit instead.

Tom

--
Tom Hughes ([hidden email])
http://compton.nu/

------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Danny Wilson
Hi Tom,

Thanks for the response.

It is a huge application, 1.5M lines not including big external dependencies like ACE/TAO. Porting over to 64bit mode would probably take months.  Any other suggestion? Perhaps disabling the generation of the offending AVX instructions with some compiler flag?

(Not sure that will work since it reports the failure inside the std:: library...)

Danny

On 27/11/2016, at 1:03 AM, Tom Hughes wrote:

> On 26/11/16 15:36, Jeffrey Walton wrote:
>>
>> Looks very similar to https://bugs.kde.org/show_bug.cgi?id=301967 .
>
> Yes that looks like an AVX instruction and those are not supported by valgrind in 32 bit code - try 64 bit instead.
>
> Tom

------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Jeffrey Walton
> Thanks for the response.
>
> It is a huge application, 1.5M lines not including big external dependencies like ACE/TAO. Porting over to 64bit mode would probably take months.  Any other suggestion? Perhaps disabling the generation of the offending AVX instructions with some compiler flag?
>

You can install a SIGILL handler to continue execution. I'm guessing
it will probably foul some Valgrind analysis. I don't know if it will
ruin all analysis.

You might also retard your optimization level a bit so vectorizing
instructions are used less frequently. Valgrind recommends -O1 or -O0
(http://valgrind.org/docs/manual/QuickStart.html), but I've noticed
GCC will utilize some vectorization even at -O1 level, like wide
memcpy's. Maybe a selection of -fno-XXX compiler options will ferret
the unwanted instructions.

You can also use Clang or GCC's sanitizers. I try to test will all the
analysis tools I can get my hands on. In cases where Valgrind does not
run, I depend on other tools, like Coverity and Sanitizers.

Jeff

------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Tom Hughes-2
In reply to this post by Danny Wilson
On 27/11/16 03:46, Danny Wilson wrote:

> It is a huge application, 1.5M lines not including big external dependencies like ACE/TAO. Porting over to 64bit mode would probably take months.  Any other suggestion? Perhaps disabling the generation of the offending AVX instructions with some compiler flag?
>
> (Not sure that will work since it reports the failure inside the std:: library...)

Yes compiling with a different CPU target is the other option, but as
you say you may need to do the libraries as well.

If you're using standard distro then it's likely the system libraries
are OK already though as a distro will compile for a fairly basic
processor to get maximum compatibility. It's only if you're using gentoo
or something that build from source that you might have an issue.

Don't forget that a lot of libstdc++ is templates that will actually
compile as part of your program...

Tom

--
Tom Hughes ([hidden email])
http://compton.nu/

------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Danny Wilson
The build machine is a core2 duo running 32-bit Centos 6.6 and custom kernel 3.10.

I recompiled the app using --march=native and --march=pentiumpro, but got the same error.

I'll try the SIGKILL handler now.

Danny

vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
==29426== valgrind: Unrecognised instruction at address 0x406ae5a.
==29426==    at 0x406AE5A: std::tr1::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned int) const (hashtable_policy.h:460)
==29426==    by 0x4353724: std::tr1::_Hashtable<DvDbDataBaseObject*, DvDbDataBaseObject*, std::allocator<DvDbDataBaseObject*>, std::_Identity<DvDbDataBaseObject*>, equalp<DvDbDataBaseObject>, DvDbDataBaseObject::Hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, true, true>::_Hashtable(unsigned int, DvDbDataBaseObject::Hash const&, std::tr1::__detail::_Mod_range_hashing const&, std::tr1::__detail::_Default_ranged_hash const&, equalp<DvDbDataBaseObject> const&, std::_Identity<DvDbDa

On 27/11/2016, at 4:29 PM, Tom Hughes wrote:

Yes compiling with a different CPU target is the other option, but as you say you may need to do the libraries as well.

If you're using standard distro then it's likely the system libraries are OK already though as a distro will compile for a fairly basic processor to get maximum compatibility. It's only if you're using gentoo or something that build from source that you might have an issue.

Don't forget that a lot of libstdc++ is templates that will actually compile as part of your program...

Tom


------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Danny Wilson
In reply to this post by Jeffrey Walton
Hi Jeff,

I put a SIGILL handler in.  Running normally without valgrind shows the signal is caught and ignored (when kill -ILL <pid> is sent)

But it seems that valgrind is disabling my signal handler.  Running under valgrind still exits with 
Valgrind will now raise a SIGILL signal which will probably kill your program.
Process terminating with default action of signal 4 (SIGILL)

I'm not familiar with clang or the gcc sanitizers.  Currently using g++ 4.4.7.  Are they an option to find my memory leak?  Valgrind looks like a dead end.

Danny

On 27/11/2016, at 12:04 PM, Jeffrey Walton wrote:

You can install a SIGILL handler to continue execution. I'm guessing
it will probably foul some Valgrind analysis. I don't know if it will
ruin all analysis.

You might also retard your optimization level a bit so vectorizing
instructions are used less frequently. Valgrind recommends -O1 or -O0
(http://valgrind.org/docs/manual/QuickStart.html), but I've noticed
GCC will utilize some vectorization even at -O1 level, like wide
memcpy's. Maybe a selection of -fno-XXX compiler options will ferret
the unwanted instructions.

You can also use Clang or GCC's sanitizers. I try to test will all the
analysis tools I can get my hands on. In cases where Valgrind does not
run, I depend on other tools, like Coverity and Sanitizers.


------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Tom Hughes-2
In reply to this post by Danny Wilson
On 27/11/16 10:28, Danny Wilson wrote:

> The build machine is a core2 duo running 32-bit Centos 6.6 and custom
> kernel 3.10.
>
> I recompiled the app using --march=native and --march=pentiumpro, but
> got the same error.

Don't use -march=native - that is telling the compiler to use everything
machine has to offer!

> I'll try the SIGKILL handler now.

That is not going to work.

Tom

--
Tom Hughes ([hidden email])
http://compton.nu/

------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Danny Wilson
The target machines uses an i5 CPU but the build machine is a core2 duo which is why I chose 'native'.  Not sure that was the right choice but it works (without Valgrind).

I've just tried -march as 'native', 'core2', and 'pentiumpro'.  All have the same result.

(and you are right: the SIGILL handler doesn't work)

Danny

On 27/11/2016, at 7:08 PM, Tom Hughes wrote:

On 27/11/16 10:28, Danny Wilson wrote:

The build machine is a core2 duo running 32-bit Centos 6.6 and custom
kernel 3.10.

I recompiled the app using --march=native and --march=pentiumpro, but
got the same error.

Don't use -march=native - that is telling the compiler to use everything machine has to offer!

I'll try the SIGKILL handler now.

That is not going to work.

Tom


------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Alex Bligh

> On 27 Nov 2016, at 16:09, Danny Wilson <[hidden email]> wrote:
>
> The target machines uses an i5 CPU but the build machine is a core2 duo which is why I chose 'native'.  Not sure that was the right choice but it works (without Valgrind).
>
> I've just tried -march as 'native', 'core2', and 'pentiumpro'.  All have the same result.

Tried building the application, or tried building the standard library? I think you said it was the latter where the illegal instructions were.

Your distribution might (or might not) have a pentium-pro compatible version for install. That should not have AVX instructions in (I would have thought).

--
Alex Bligh





------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Danny Wilson
On 28/11/2016, at 8:07 PM, Alex Bligh wrote:

>
>> On 27 Nov 2016, at 16:09, Danny Wilson <[hidden email]> wrote:
>>
>> The target machines uses an i5 CPU but the build machine is a core2 duo which is why I chose 'native'.  Not sure that was the right choice but it works (without Valgrind).
>>
>> I've just tried -march as 'native', 'core2', and 'pentiumpro'.  All have the same result.
>
> Tried building the application, or tried building the standard library? I think you said it was the latter where the illegal instructions were.
>
> Your distribution might (or might not) have a pentium-pro compatible version for install. That should not have AVX instructions in (I would have thought)
> --
> Alex Bligh

Hi Alex, rebuilding the standard libraries is a little beyond our scope (and I'd figure it unlikely that such a basic function of the c++ library had a memory leak.  Something like that would be well published).  As Tom pointed out, it could also be from a std template compiled in from my program.

Good question now is how to disable generation of the unsupported instructions...
------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Jeff Hammond


On Mon, Nov 28, 2016 at 5:29 PM, Danny Wilson <[hidden email]> wrote:
On 28/11/2016, at 8:07 PM, Alex Bligh wrote:
>
>> On 27 Nov 2016, at 16:09, Danny Wilson <[hidden email]> wrote:
>>
>> The target machines uses an i5 CPU but the build machine is a core2 duo which is why I chose 'native'.  Not sure that was the right choice but it works (without Valgrind).
>>
>> I've just tried -march as 'native', 'core2', and 'pentiumpro'.  All have the same result.
>
> Tried building the application, or tried building the standard library? I think you said it was the latter where the illegal instructions were.
>
> Your distribution might (or might not) have a pentium-pro compatible version for install. That should not have AVX instructions in (I would have thought)
> --
> Alex Bligh

Hi Alex, rebuilding the standard libraries is a little beyond our scope (and I'd figure it unlikely that such a basic function of the c++ library had a memory leak.  Something like that would be well published).  As Tom pointed out, it could also be from a std template compiled in from my program.

Good question now is how to disable generation of the unsupported instructions...

 
Based upon your prior report showing the illegal instruction associated with std:tr1 code (re-included below), I recommend you build GCC from source so that your C++ standard library is compiled with generic instructions.  Building GCC sounds daunting but I do it all the time.  My poorly curated notes are https://github.com/jeffhammond/HPCInfo/wiki/GCC if you like to copy+paste from the internet :-)

Best,

Jeff

vex x86->IR: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45
==29426== valgrind: Unrecognised instruction at address 0x406ae5a.
==29426==    at 0x406AE5A: std::tr1::__detail::_Prime_rehash_policy::_M_next_bkt(unsigned int) const (hashtable_policy.h:460)
==29426==    by 0x4353724: std::tr1::_Hashtable<DvDbDataBaseObject*, DvDbDataBaseObject*, std::allocator<DvDbDataBaseObject*>, std::_Identity<DvDbDataBaseObject*>, equalp<DvDbDataBaseObject>, DvDbDataBaseObject::Hash, std::tr1::__detail::_Mod_range_hashing, std::tr1::__detail::_Default_ranged_hash, std::tr1::__detail::_Prime_rehash_policy, false, true, true>::_Hashtable(unsigned int, DvDbDataBaseObject::Hash const&, std::tr1::__detail::_Mod_range_hashing const&, std::tr1::__detail::_Default_ranged_hash const&, equalp<DvDbDataBaseObject> const&, std::_Identity<DvDbDa


------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Alex Bligh
In reply to this post by Danny Wilson
Danny,

> On 29 Nov 2016, at 01:29, Danny Wilson <[hidden email]> wrote:
>
> Hi Alex, rebuilding the standard libraries is a little beyond our scope (and I'd figure it unlikely that such a basic function of the c++ library had a memory leak.  Something like that would be well published).  As Tom pointed out, it could also be from a std template compiled in from my program.
>
> Good question now is how to disable generation of the unsupported instructions...

I'm not saying the leak is in the standard library, just that the instructions that are traced are in the standard library. I'm also not saying you necessarily need to recompile (just that recompiling the application won't fix it if the instructions that are problematic are in the standard library) - rather I'm suggesting you attempt to obtain a precompiled version of the standard library for a lesser processor.

Depending on your distribution, recompilation should actually be pretty trivial. On Debian compatible distros its as simple as getting the source (one command) and using 'debuild'. On RPM distros, from memory you get the srpm and go from there.

--
Alex Bligh





------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Tom Hughes-2
On 29/11/16 09:42, Alex Bligh wrote:

>> On 29 Nov 2016, at 01:29, Danny Wilson <[hidden email]> wrote:
>>
>> Hi Alex, rebuilding the standard libraries is a little beyond our scope (and I'd figure it unlikely that such a basic function of the c++ library had a memory leak.  Something like that would be well published).  As Tom pointed out, it could also be from a std template compiled in from my program.
>>
>> Good question now is how to disable generation of the unsupported instructions...
>
> I'm not saying the leak is in the standard library, just that the instructions that are traced are in the standard library. I'm also not saying you necessarily need to recompile (just that recompiling the application won't fix it if the instructions that are problematic are in the standard library) - rather I'm suggesting you attempt to obtain a precompiled version of the standard library for a lesser processor.

Except that much of the C++ standard library is templates that compiles
as part of his application and not a library in the traditional sense.

> Depending on your distribution, recompilation should actually be pretty trivial. On Debian compatible distros its as simple as getting the source (one command) and using 'debuild'. On RPM distros, from memory you get the srpm and go from there.

No distribution that does precompiled packages is going to have built
with AVX enabled so trying to recompile distro provided libraries is
almost certainly a red herring.

Danny - what distro are you using, and what architecture flags are you
specifying when building your own program?

Tom

--
Tom Hughes ([hidden email])
http://compton.nu/

------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Danny Wilson
In reply to this post by Jeff Hammond
Hi Jeff,

Thanks, I'll give it a shot!

From the previous messages in this thread, the target machine is an 6500 series i5.  When rebuilding gcc, what value for -march would be appropriate?

Danny

On 29/11/2016, at 12:35 PM, Jeff Hammond wrote:

Based upon your prior report showing the illegal instruction associated with std:tr1 code (re-included below), I recommend you build GCC from source so that your C++ standard library is compiled with generic instructions.  Building GCC sounds daunting but I do it all the time.  My poorly curated notes are https://github.com/jeffhammond/HPCInfo/wiki/GCC if you like to copy+paste from the internet :-)


------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Danny Wilson
In reply to this post by Tom Hughes-2
Hi Tom,

For -march I've tried 'native', 'pentiumpro' and 'core2'.
When compiling for valgrind, also -O0.

# cat /etc/redhat-release
CentOS release 6.6 (Final)

# uname -a
Linux dvstor5 3.10.80-1.el6.elrepo.i686 #1 SMP Sun Jun 7 08:15:14 EDT 2015 i686 i686 i386 GNU/Linux

Danny

On 29/11/2016, at 5:45 PM, Tom Hughes wrote:

> No distribution that does precompiled packages is going to have built with AVX enabled so trying to recompile distro provided libraries is almost certainly a red herring.
>
> Danny - what distro are you using, and what architecture flags are you specifying when building your own program?
>
> Tom


------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Tom Hughes-2
On 29/11/16 12:10, Danny Wilson wrote:

> For -march I've tried 'native', 'pentiumpro' and 'core2'.
> When compiling for valgrind, also -O0.

Well native is definitely not going to work, and core2 might be pushing
it, but pentiumpro should be fine. To be honest just leaving out -march
and -mcpu should be ok as it will default to something relatively basic.

> # cat /etc/redhat-release
> CentOS release 6.6 (Final)
>
> # uname -a
> Linux dvstor5 3.10.80-1.el6.elrepo.i686 #1 SMP Sun Jun 7 08:15:14 EDT 2015 i686 i686 i386 GNU/Linux

Right, so I'm sure the system libraries are not going to be an issue for
CentOS 6 on 32 bit.

Tom

--
Tom Hughes ([hidden email])
http://compton.nu/

------------------------------------------------------------------------------
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Danny Wilson
Super - thanks so much.  Working on small emergency so will be able to get back to this on Saturday.  Fingers crossed.

Danny

On 29/11/2016, at 8:19 PM, Tom Hughes wrote:

For -march I've tried 'native', 'pentiumpro' and 'core2'.
When compiling for valgrind, also -O0.

Well native is definitely not going to work, and core2 might be pushing it, but pentiumpro should be fine. To be honest just leaving out -march and -mcpu should be ok as it will default to something relatively basic.

# cat /etc/redhat-release
CentOS release 6.6 (Final)

# uname -a
Linux dvstor5 3.10.80-1.el6.elrepo.i686 #1 SMP Sun Jun 7 08:15:14 EDT 2015 i686 i686 i386 GNU/Linux

Right, so I'm sure the system libraries are not going to be an issue for CentOS 6 on 32 bit.


------------------------------------------------------------------------------

_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

Danny Wilson
In reply to this post by Tom Hughes-2
Hi Tom,

I omitted -march (didn't have -mcpu), but unfortunately exactly same error.

Now recompiling g++ 4.4.7 from source as per suggestion from Jeff Hammond.

Danny

On 29/11/2016, at 8:19 PM, Tom Hughes wrote:

For -march I've tried 'native', 'pentiumpro' and 'core2'.
When compiling for valgrind, also -O0.

Well native is definitely not going to work, and core2 might be pushing it, but pentiumpro should be fine. To be honest just leaving out -march and -mcpu should be ok as it will default to something relatively basic.


------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
Valgrind-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
12
Loading...