|
From: Danny W. <da...@to...> - 2016-11-26 03:10:10
|
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: |
|
From: Jeffrey W. <nol...@gm...> - 2016-11-26 15:36:24
|
On Fri, Nov 25, 2016 at 9:38 PM, Danny Wilson <da...@to...> 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 |
|
From: Tom H. <to...@co...> - 2016-11-26 17:03:14
|
On 26/11/16 15:36, Jeffrey Walton wrote: > On Fri, Nov 25, 2016 at 9:38 PM, Danny Wilson <da...@to...> 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 (to...@co...) http://compton.nu/ |
|
From: Jeffrey W. <nol...@gm...> - 2016-11-27 04:04:47
|
> 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 |
|
From: Danny W. <da...@to...> - 2016-11-27 10:52:54
|
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. |
|
From: Danny W. <da...@to...> - 2016-11-27 04:18:09
|
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 |
|
From: Tom H. <to...@co...> - 2016-11-27 08:29:44
|
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 (to...@co...) http://compton.nu/ |
|
From: Danny W. <da...@to...> - 2016-11-27 10:33:20
|
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 |
|
From: Tom H. <to...@co...> - 2016-11-27 11:08:33
|
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 (to...@co...) http://compton.nu/ |
|
From: Danny W. <da...@to...> - 2016-11-27 16:41:01
|
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 |
|
From: Alex B. <al...@al...> - 2016-11-28 12:07:50
|
> On 27 Nov 2016, at 16:09, Danny Wilson <da...@to...> 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 |
|
From: Danny W. <da...@to...> - 2016-11-29 01:35:06
|
On 28/11/2016, at 8:07 PM, Alex Bligh wrote: > >> On 27 Nov 2016, at 16:09, Danny Wilson <da...@to...> 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... |
|
From: Jeff H. <jef...@gm...> - 2016-11-29 04:35:47
|
On Mon, Nov 28, 2016 at 5:29 PM, Danny Wilson <da...@to...> wrote: > On 28/11/2016, at 8:07 PM, Alex Bligh wrote: > > > >> On 27 Nov 2016, at 16:09, Danny Wilson <da...@to...> 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 -- Jeff Hammond jef...@gm... http://jeffhammond.github.io/ |
|
From: Danny W. <da...@to...> - 2016-11-29 09:57:29
|
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 :-) |
|
From: Danny W. <da...@to...> - 2016-12-06 10:30:08
|
Hi Jeff,
I've downloaded and compiled gcc 4.4.7 (same as stock Centos version).
Unfortunately, the program no longer compiles, giving an error "This platform does not support exception propagation". (I don't know what that means).
Any suggestion on how to get around this?
Thanks,
Danny
/home/dvmon/bin/gcc-4.4.7/bin/g++ -c -g -O0 -DDEBUG -DCHECK_ALL -DDVMONDEBUG -DDV_BUILD_DATE=\"2016.12.06-17:58:21\" -Wall -Wextra -Wno-sign-compare -Wcast-align -DDV_MAJOR_VERSION=6 -DDV_MINOR_VERSION=0 -DDV_BETA_INDICATOR= -DDV_BUILD_NUMBER=27 -DDV_INSTALL_DIR=\"/usr/local/dvstation\" -ftemplate-depth-32 -march=native -ggdb -fPIC -DACE_HAS_NO_THROW_SPEC -D_GNU_SOURCE -D__ACE_INLINE__ -I../../include -I../../src -I/mnt/swdevel/DVMon/source_build/ext/ACE -I/mnt/swdevel/DVMon/source_build/ext/ACE/TAO -I/mnt/swdevel/DVMon/source_build/ext/ACE/TAO/orbsvcs -I/usr/include/libxml2 -Iinclude -DAGENTPP_NAMESPACE -I/usr/lib/qt-3.3/include -I/usr/include/pcap -o DvMain.o DvMain.cpp
In file included from ../../include/com/DvComDefaultExceptionHandler.h:76,
from DvMain.cpp:26:
/home/dvmon/bin/gcc-4.4.7/lib/gcc/i686-pc-linux-gnu/4.4.7/../../../../include/c++/4.4.7/exception_ptr.h:40:4: error: #error This platform does not support exception propagation.
make[1]: *** [DvMain.o] Error 1
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 :-)
|
|
From: Alex B. <al...@al...> - 2016-11-29 09:42:39
|
Danny, > On 29 Nov 2016, at 01:29, Danny Wilson <da...@to...> 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 |
|
From: Tom H. <to...@co...> - 2016-11-29 09:45:48
|
On 29/11/16 09:42, Alex Bligh wrote: >> On 29 Nov 2016, at 01:29, Danny Wilson <da...@to...> 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 (to...@co...) http://compton.nu/ |
|
From: Danny W. <da...@to...> - 2016-11-29 12:15:41
|
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 |
|
From: Tom H. <to...@co...> - 2016-11-29 12:19:39
|
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 (to...@co...) http://compton.nu/ |
|
From: Danny W. <da...@to...> - 2016-11-29 13:31:12
|
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. |
|
From: Danny W. <da...@to...> - 2016-12-06 10:26:15
|
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. |