valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] .gcda files are not generated when run on valgrind

[Ravi K. <rav...@gm...>]

Hi,

Could you please respond for the below problem as it is very important.

We will appreciate your efforts.

Thanks in advance,

Regards,
Ravi

On Wed, Nov 23, 2016 at 1:05 PM, Ravi Kaipu <rav...@gm...> wrote:

> Hi,
>
> We have a huge code base which requires a lot of time to check the runtime
> errors and code coverage (using lcov tool) separately
>
> We have built  the components with coverage flags and are now trying to
> run on valgrind for .gcda files to find coverage. but, .gcda files are not
> generated sometimes when run on valgrind. But the same components when run
> with coverage flags without valgrind generate .gcda files
>
> We are doing this to reduce the execution time of the test case . Can we
> rely on this method or shall we avoid running on valgrind with coverage
> flags to get coverage
>
> Has anyone tried like this before ? appreciate any help on this .
>
> Thanks in advance,
>
> Regards,
> Ravi
>
>

Re: [Valgrind-users] Valgrind may not compatible to gcc(4.9), Why?

[John R. <jr...@bi...>]

On 11/29/2016 06:48 PM, Wuweijia wrote:
> I compile a demo testcase with gcc 4.9 , run it in aarch64 server with valgrind . valgrind report there is some memory error as below. I do not think that it maybe a problem.

The testAlgo.cpp that was in the attached testcase.rar compiles to less
than 2KB of code using gcc-4.9.2 on a RaspberryPi3 running in 32-bit mode.
So you should run "g++ -S testAlgo.cpp" then look at testAlgo.s and
analyze the generated code.  Or, run "objdump -d ./a.out" on the binary.
Anyway: "g++ testAlgo.cpp; valgrind-3.12 ./a.out" gave no complaints.

[Valgrind-users] Valgrind may not compatible to gcc(4.9), Why?

[Wuweijia <wuw...@hu...>]

I compile a demo testcase with gcc 4.9 , run it in aarch64 server with valgrind . valgrind report there is some memory error as below. I do not think that it maybe a problem.

==6494== 1 errors in context 1 of 4:
==6494== Use of uninitialised value of size 4
==6494==    at 0x1089F8: main (testAlgo.cpp:84)
==6494==
==6494==
==6494== 1 errors in context 2 of 4:
==6494== Use of uninitialised value of size 4
==6494==    at 0x10898E: fun() (testAlgo.cpp:67)
==6494==    by 0x1089D9: main (testAlgo.cpp:80)
==6494==
==6494==
==6494== 2 errors in context 3 of 4:
==6494== Invalid write of size 4
==6494==    at 0x10885C: A::A(int const&) (testAlgo.cpp:36)
==6494==    by 0x108973: fun() (testAlgo.cpp:64)
==6494==    by 0x1089D9: main (testAlgo.cpp:80)
==6494==  Address 0xfed715b8 is on thread 1's stack
==6494==  16 bytes below stack pointer


And then I compile a demo testcase with clang, run it in aarch64 server with valgrind . valgrind report there is no memory error



Valgrind version: valgrind-3.11.0.SVN.aosp

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

[Danny W. <da...@to...>]

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.

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

[Tom H. <to...@co...>]

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/

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

[Danny W. <da...@to...>]

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

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

[Danny W. <da...@to...>]

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 :-)

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

[Tom H. <to...@co...>]

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/

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

[Alex B. <al...@al...>]

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

Re: [Valgrind-users] The config takes exception when the address of an load/store is unaligned

[John R. <jr...@bi...>]

> Error: The config takes exception when the address of an load/store is unaligned. The address 0xfead844c is not properly aligned.

That complaint is from the application, and not from valgrind (memcheck).
The substring 'takes exception' does not appear anywhere in the valgrind source code.
Also, every line that _is_ a valgrind complaint begins with "==PID==" where PID
is the process ID in decimal.

The address 0xfead844c is 4-byte aligned.  What alignment is the application expecting?
Look at the source code of the application to find out.  malloc() claims that each
newly-allocated block is "suitably aligned for any built-in type", and memcheck's
replacement for malloc() obeys this rule.  On aarch64 the maximum required alignment
is 16-byte alignment, but this is required only when using the stack pointer register
SP as a base register, or for special exclusive and explicitly-ordered memory accesses
that are part of multi-threaded synchronization.  Otherwise, most compilers and
runtime libraries use natural alignment: sizeof(x) divides &x for any builtin type;
and align_of(struct) is max(align_of(members)).  Therefore in practice the maximum
alignment is likely to be 8-byte alignment because of the 'double' type.
On x86_64 it is 16 bytes because some "multi-media" SIMD instructions require
128-bit alignment for operands in memory.  aarch64 does not have this requirement,
although there are VectorFloatingPoint and other SIMD loads and stores which may
execute faster when aligned to 4 times the alignment of an individual element.

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

[Jeff H. <jef...@gm...>]

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/

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

[Danny W. <da...@to...>]

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...

[Valgrind-users] Helgrind and Meyers' singletons

[Schmidt, A. <adr...@si...>]

Dear all,

The program below uses thread-safe static initialization to implement a singleton.
When analyzing this with Helgrind, a data race is reported between the initialization of "val" in the constructor (executed by thread 1) and the increment operation (executed by thread 2). This is expected, as Helgrind does not "understand" the synchronization generated by the compiler.

I'm looking for a way to get rid of the false positives in such cases, and experimented with annotations. I found that placing
    ANNOTATE_HAPPENS_AFTER(&inst);
    ANNOTATE_HAPPENS_BEFORE(&inst);
inside the getInstance() method (either in this order or reversed) makes the Helgrind warnings disappear.

Is this a valid approach? Are there possible side-effects? Could this "break" the analysis and lead to other data races going undetected?

Thanks,
Adriaan


#include <unistd.h>
#include <pthread.h>

class MySingleton {
public:
    MySingleton(int x) : val(x) {
        pthread_mutex_init(&lock, NULL);
    }
    static MySingleton *getInstance() {
        static MySingleton inst(0);
        //ANNOTATE_HAPPENS_AFTER(&inst);
        //ANNOTATE_HAPPENS_BEFORE(&inst);
        return &inst;
    }
    void increment() {
        pthread_mutex_lock(&lock);
        val++;
        pthread_mutex_unlock(&lock);
    };
private:
    pthread_mutex_t lock;
    int val;
};

void *thread_start(void *arg) {
    sleep(1);
    MySingleton::getInstance()->increment();
}

int main() {
    pthread_t a;
    pthread_create(&a, NULL, thread_start, NULL);
    MySingleton::getInstance();
    pthread_join(a, NULL);
}

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

[Alex B. <al...@al...>]

> 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

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

[Danny W. <da...@to...>]

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

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

[Tom H. <to...@co...>]

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/

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

[Danny W. <da...@to...>]

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.

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

[Danny W. <da...@to...>]

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

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

[Tom H. <to...@co...>]

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/

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

[Danny W. <da...@to...>]

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

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

[Jeffrey W. <nol...@gm...>]

> 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

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

[Tom H. <to...@co...>]

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/

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

[Jeffrey W. <nol...@gm...>]

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

[Valgrind-users] The config takes exception when the address of an load/store is unaligned

[Wuweijia <wuw...@hu...>]

I am new. I run valgrind in arm64 server, it show me the information in red, and then valgrind exit. What problem is it ? Can you tell me how to make continue to run ( not exit ).


[EIS_IVP][I] temporal_denoise_multi_frame:1885 frame[1]: imgSize / 3 / 2 = 1331712, motionPixNum = 0

Error: The config takes exception when the address of an load/store is unaligned. The address 0xfead844c is not properly aligned.
==32249==
==32249== HEAP SUMMARY:
==32249==     in use at exit: 60,503,682 bytes in 38 blocks
==32249==   total heap usage: 3,112 allocs, 3,074 frees, 131,593,040 bytes allocated
==32249==
==32249== LEAK SUMMARY:
==32249==    definitely lost: 204 bytes in 17 blocks
==32249==    indirectly lost: 180,263 bytes in 1 blocks
==32249==      possibly lost: 60,320,908 bytes in 16 blocks
==32249==    still reachable: 2,307 bytes in 4 blocks
==32249==         suppressed: 0 bytes in 0 blocks
==32249== Rerun with --leak-check=full to see details of leaked memory
==32249==
==32249== For counts of detected and suppressed errors, rerun with: -v
==32249== Use --track-origins=yes to see where uninitialised values come from


Test machine information
CPU aarch64
OS  android 7.0
Valgrind  3.11


What anything else do  you need ?

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

[Danny W. <da...@to...>]

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: