Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-12-06 Thread Danny Wilson 
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 :-)

--
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-12-06 Thread Danny Wilson 
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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-29 Thread 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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

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

>> On 29 Nov 2016, at 01:29, Danny Wilson  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 (t...@compton.nu)
http://compton.nu/

--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-29 Thread Alex Bligh 
Danny,

> On 29 Nov 2016, at 01:29, Danny Wilson  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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-28 Thread Danny Wilson 
On 28/11/2016, at 8:07 PM, Alex Bligh wrote:
> 
>> On 27 Nov 2016, at 16:09, Danny Wilson  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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-27 Thread 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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-27 Thread Tom Hughes 
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 (t...@compton.nu)
http://compton.nu/

--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-27 Thread Danny Wilson 
Hi Jeff,

I put a SIGILL handler in.  Running normally without valgrind shows the signal 
is caught and ignored (when kill -ILL  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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-27 Thread 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*, std::allocator, 
> std::_Identity, equalp, 
> 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 
> const&, std::_Identity 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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-27 Thread Tom Hughes 
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 (t...@compton.nu)
http://compton.nu/

--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-26 Thread 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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-26 Thread 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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-26 Thread Tom Hughes 
On 26/11/16 15:36, Jeffrey Walton wrote:
> On Fri, Nov 25, 2016 at 9:38 PM, Danny Wilson  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 (t...@compton.nu)
http://compton.nu/

--
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] unhandled instruction bytes: 0xC5 0xF9 0x6E 0x45

2016-11-26 Thread Jeffrey Walton 
On Fri, Nov 25, 2016 at 9:38 PM, Danny Wilson  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
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users