valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Unrecognised instruction at address

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

On 06/02/14 09:56, Vivek Sundararajan wrote:
> Thanks for the reply Tom!
>
> To clarify: Valgrind has to be built in 64 bit mode before running
> against my app to profile it?

Well you will need a 64 bit valgrid to work with 64 bit programs yes bit 
valgrind normally builds both 32 and 64 bit support unless you tell it 
not to.

The first thing though is to build the program you are trying to run 
valgrind on as a 64 bit program.

Tom

>
>
> On 4 February 2014 17:05, Tom Hughes <to...@co...
> <mailto:to...@co...>> wrote:
>
>     On 04/02/14 11:03, Vivek Sundararajan wrote:
>
>         Below is the output I get stating "unhandled instruction".
>         Is this because of depending on libraries that are not build
>         with the
>         above flags?
>
>
>     It's the AESKEYGENASSIST instruction which, like most of the more
>     recent instructions, is only supported in 64 bit mode at the moment
>     and you are trying to use it in 32 bit code.
>
>     In https://bugs.kde.org/show_bug.__cgi?id=296577
>     <https://bugs.kde.org/show_bug.cgi?id=296577> Julian commented:
>
>      > This is AESKEYGENASSIST, which is supported in 64 bit mode but not 32
>      > bit. Realistically I don't think it will get supported in 32 bit mode
>      > -- that doesn't support anything after SSSE3. Can you develop in 64
>      > bit mode instead? The main support emphasis now is x86_64 (64 bit)
>      > and ARM; x86 (32 bit) is more-or-less "legacy".
>
>     Note that the bug I reference above is a bit confused because
>     somebody raised it about one instruction and then somebody else
>     added a comment about a different instruction.
>
>     Tom
>
>     --
>     Tom Hughes (to...@co... <mailto:to...@co...>)
>     http://compton.nu/
>
>
>
>
> --
> Regards,
> Vivek.S


-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Unrecognised instruction at address

[Vivek S. <s.v...@gm...>]

Thanks for the reply Tom!

To clarify: Valgrind has to be built in 64 bit mode before running against
my app to profile it?



On 4 February 2014 17:05, Tom Hughes <to...@co...> wrote:

> On 04/02/14 11:03, Vivek Sundararajan wrote:
>
>  Below is the output I get stating "unhandled instruction".
>> Is this because of depending on libraries that are not build with the
>> above flags?
>>
>
> It's the AESKEYGENASSIST instruction which, like most of the more recent
> instructions, is only supported in 64 bit mode at the moment and you are
> trying to use it in 32 bit code.
>
> In https://bugs.kde.org/show_bug.cgi?id=296577 Julian commented:
>
> > This is AESKEYGENASSIST, which is supported in 64 bit mode but not 32
> > bit. Realistically I don't think it will get supported in 32 bit mode
> > -- that doesn't support anything after SSSE3. Can you develop in 64
> > bit mode instead? The main support emphasis now is x86_64 (64 bit)
> > and ARM; x86 (32 bit) is more-or-less "legacy".
>
> Note that the bug I reference above is a bit confused because somebody
> raised it about one instruction and then somebody else added a comment
> about a different instruction.
>
> Tom
>
> --
> Tom Hughes (to...@co...)
> http://compton.nu/
>



-- 
Regards,
Vivek.S

Re: [Valgrind-users] unable to start child application

[manik s. <she...@gm...>]

My starting script sets lot of environment variables for my application to
run.
I can not place valgrind inside it, because that will mess-up with the
configured paths for valgrind.

Therefore, I am using valgrind to start the script.
The thing I have noticed is that when I skip my child application through
the use of "--trace-children-skip" , everything works just fine and my
application is able to come up nicely. However, without skipping it
segfaults.


On Wed, Feb 5, 2014 at 11:13 PM, Fred Smith <fs...@co...> wrote:

>  I use it all the time on a program that starts from a shellscript. Just
> modify the line of the script where your program is invoked so that it uses
> valgrind (with appropriate args) to start your program.
>
>
>
> *Fred Smith*
>
> *Senior Applications Programmer/Analyst*
>
> *Computrition, Inc.*
>
> *175 Middlesex Turnpike*
>
> *Bedford, MA 01730*
>
> *ph: 781-275-4488 x5013*
>
> *fax: 781-357-4100*
>
>
>
>
>
> *From:* manik sheeri [mailto:she...@gm...]
> *Sent:* Wednesday, February 05, 2014 6:02 AM
> *To:* val...@li...
> *Subject:* [Valgrind-users] unable to start child application
>
>
>
> Hi,
>
>
>
> I have an application which is started by a shell script.
>
> But before that application is forked , there are many daemon processes
> started by the start shell script.
>
>
>
> Unfortunately, when I use valgrind to initiate the start script with
> "--trace-children" enabled, the script exits at some point while starting a
> particular daemon.
>
>
>
> My question is, can I simply give my interested executable in the command
> line, so that valgrind run everything smoothly but only instruments the
> given executable of interest. ???
>
>
>
> thanks,
>
> sheeri
>
>   ­­
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>


-- 
Manik Sheeri
09582990906

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

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

On Wed, Feb 5, 2014 at 6:06 PM, Tom Hughes <to...@co...> wrote:
> On 05/02/14 23:00, Jeffrey Walton wrote:
>
>> Well, I'm not sure how to proceed since RAND_init_fips is the linchpin.
>>
>> A call to ... -> RAND_init_fips -> ... -> fips_aes_encrypt is OK.
>>
>> A call to ... -> AES_encrypt -> ... -> fips_aes_encrypt is BAD.
>>
>> I'm fairly certain I need to include RAND_init_fips to rule out a
>> legitimate uninitialized read, but I'm not sure how to do it.
>>
>> Any ideas how to craft this rule?
>
>
> You can't. There is no way to write a suppression which says "don't worry
> about reads from the memory that was allocated at location X" which is what
> you are tryng to do.
Thanks Tom. That's not the answer I wanted :)

Jeff

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

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

On 05/02/14 23:00, Jeffrey Walton wrote:

> Well, I'm not sure how to proceed since RAND_init_fips is the linchpin.
>
> A call to ... -> RAND_init_fips -> ... -> fips_aes_encrypt is OK.
>
> A call to ... -> AES_encrypt -> ... -> fips_aes_encrypt is BAD.
>
> I'm fairly certain I need to include RAND_init_fips to rule out a
> legitimate uninitialized read, but I'm not sure how to do it.
>
> Any ideas how to craft this rule?

You can't. There is no way to write a suppression which says "don't 
worry about reads from the memory that was allocated at location X" 
which is what you are tryng to do.

Your problem presumably is that something is deliberately mixing 
uninitialised memory into the random pool - whether that is a sensible 
idea is a good question but lets not repeat the whole Debian openssl 
debate again...

The best fix is to have whatever is doing that use a client request to 
deliberately mark the data in the random as initialised because in a 
logical sense it is even though strictly speaking it isn't.

Otherwise you're stuck trying to suppress everything that winds up 
depending on data from the random pool.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

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

On Wed, Feb 5, 2014 at 5:54 PM, Tom Hughes <to...@co...> wrote:
> On 05/02/14 22:49, Jeffrey Walton wrote:
>
>> Are you stating those are two different findings? If they are two
>> different findings, shouldn't there be two different:
>
>
> Well it's one finding, but there are two pieces of information associated
> with that finding.
>
> The first is the location where the uninitialised data was used and the
> second (which occurred at some earlier point during the program's execution)
> is the location where the memory containing the uninitialised data was
> allocated.
>
> The two are separated by the "Uninitialised value was created by..." line
> which tells you that what follows is the location of the allocation.
>
> Because suppressions match at the point where the data is accessed they
> match against the stack at that point in time.
Thanks Tom.

Well, I'm not sure how to proceed since RAND_init_fips is the linchpin.

A call to ... -> RAND_init_fips -> ... -> fips_aes_encrypt is OK.

A call to ... -> AES_encrypt -> ... -> fips_aes_encrypt is BAD.

I'm fairly certain I need to include RAND_init_fips to rule out a
legitimate uninitialized read, but I'm not sure how to do it.

Any ideas how to craft this rule?

Thanks in advance.

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

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

On 05/02/14 22:49, Jeffrey Walton wrote:

> Are you stating those are two different findings? If they are two
> different findings, shouldn't there be two different:

Well it's one finding, but there are two pieces of information 
associated with that finding.

The first is the location where the uninitialised data was used and the 
second (which occurred at some earlier point during the program's 
execution) is the location where the memory containing the uninitialised 
data was allocated.

The two are separated by the "Uninitialised value was created by..." 
line which tells you that what follows is the location of the allocation.

Because suppressions match at the point where the data is accessed they 
match against the stack at that point in time.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

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

Thanks Tom. So apparently I'm doing something wrong.

On Wed, Feb 5, 2014 at 5:40 PM, Tom Hughes <to...@co...> wrote:
> On 05/02/14 22:21, Jeffrey Walton wrote:
>
>> ==6516== Use of uninitialised value of size 8
>> ==6516==    at 0x533B449: _x86_64_AES_encrypt_compact (in
>> /usr/local/ssl/lib/libcrypto.so.1.0.0)
>> ==6516==    by 0x533B6DA: fips_aes_encrypt (in
>> /usr/local/ssl/lib/libcrypto.so.1.0.0)
>> ==6516==    by 0x56FBC47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
>> ==6516==    by 0x56FBD27: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
>> ==6516==    by 0x56FBE47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
>> ==6516==    by 0xFFEFFFE17: ???
>
>
> So this is the stack you are matching against.
That's part of the finding, but not the whole finding.

>> {
>>     RAND_init_fips_1
>>     Memcheck:Cond
>>     ...
>>     fun:RAND_init_fips
>>     ...
>> }
>
>
> and this is one of the match rules, which uses a function that is not in the
> stack being matched.
>
>
>> Any ideas what I'm doing wrong?
>
>
> Yes, you're trying to match against the location where the memory is
> allocated, but suppression rules (except for leak suppressions) match
> against the stack at the point the error is detected.

It appears to me that the finding ends with:

==6566== Use of uninitialised value of size 8
==6566==    at 0x533B449: _x86_64_AES_encrypt_compact (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)

And starts with:

==6566==    by 0x4103E7: DoStartupOpenSSL() (ac-openssl-1.cpp:494)
==6566==    by 0x419504: main (main.cpp:69)

(Sorry to do it in reverse order. It seems natural because it follows
Valgrind's onscreen output).

Are you stating those are two different findings? If they are two
different findings, shouldn't there be two different:

==6566==    by 0x4103E7: DoStartupOpenSSL() (ac-openssl-1.cpp:494)
==6566==    by 0x419504: main (main.cpp:69)

Jeff

Re: [Valgrind-users] Frame-level wildcard not matching in suppression rule?

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

On 05/02/14 22:21, Jeffrey Walton wrote:

> ==6516== Use of uninitialised value of size 8
> ==6516==    at 0x533B449: _x86_64_AES_encrypt_compact (in
> /usr/local/ssl/lib/libcrypto.so.1.0.0)
> ==6516==    by 0x533B6DA: fips_aes_encrypt (in
> /usr/local/ssl/lib/libcrypto.so.1.0.0)
> ==6516==    by 0x56FBC47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
> ==6516==    by 0x56FBD27: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
> ==6516==    by 0x56FBE47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
> ==6516==    by 0xFFEFFFE17: ???

So this is the stack you are matching against.

> {
>     RAND_init_fips_1
>     Memcheck:Cond
>     ...
>     fun:RAND_init_fips
>     ...
> }

and this is one of the match rules, which uses a function that is not in 
the stack being matched.

> Any ideas what I'm doing wrong?

Yes, you're trying to match against the location where the memory is 
allocated, but suppression rules (except for leak suppressions) match 
against the stack at the point the error is detected.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Frame-level wildcard not matching in suppression rule?

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

I'm having trouble writing a suppression rule.

Here's the finding:

==6516== Use of uninitialised value of size 8
==6516==    at 0x533B449: _x86_64_AES_encrypt_compact (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x533B6DA: fips_aes_encrypt (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x56FBC47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x56FBD27: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x56FBE47: ??? (in /usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0xFFEFFFE17: ???
==6516==  Uninitialised value was created by a heap allocation
==6516==    at 0x4C28D84: malloc (vg_replace_malloc.c:291)
==6516==    by 0x53575AF: CRYPTO_malloc (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x53FB52B: drbg_get_entropy (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x534C312: fips_get_entropy (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x534CABE: FIPS_drbg_instantiate (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x53FB94E: RAND_init_fips (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x5403F5D: EVP_add_cipher (in
/usr/local/ssl/lib/libcrypto.so.1.0.0)
==6516==    by 0x507B7C0: SSL_library_init (in
/usr/local/ssl/lib/libssl.so.1.0.0)
==6516==    by 0x4103E7: DoStartupOpenSSL() (ac-openssl-1.cpp:494)
==6516==    by 0x419504: main (main.cpp:69)
==6516==

Here are the rules I'm trying to use to suppress the finding:

{
   RAND_init_fips_1
   Memcheck:Cond
   ...
   fun:RAND_init_fips
   ...
}

{
   RAND_init_fips_2
   Memcheck:Value8
   ...
   fun:RAND_init_fips
   ...
}

{
   RAND_init_fips_3
   Memcheck:Value4
   ...
   fun:RAND_init_fips
   ...
}

I believe I'm using the frame-level wildcard according to the manual
(under Section 2.5, http://valgrind.org/docs/manual/manual-core.html):

    A location line may also be simply "..." (three dots). This is a
    frame-level wildcard, which matches zero or more frames.
    Frame level wildcards are useful because they make it easy
    to ignore varying numbers of uninteresting frames in between
    frames of interest. That is often important when writing
    suppressions which are intended to be robust against
    variations in the amount of function inlining done by compilers.

Any ideas what I'm doing wrong?

Thanks in advance.

**********

My version of Valgrind (built from sources):

$ which valgrind
/usr/local/bin/valgrind
$ valgrind --version
valgrind-3.9.0

And the OS (Debian 7.3, x64, fully patched):

$ uname -a
Linux debian-q500 3.2.0-4-amd64 #1 SMP Debian 3.2.51-1 x86_64 GNU/Linux

Re: [Valgrind-users] unable to start child application

[Fred S. <fs...@co...>]

I use it all the time on a program that starts from a shellscript. Just modify the line of the script where your program is invoked so that it uses valgrind (with appropriate args) to start your program.

Fred Smith
Senior Applications Programmer/Analyst
Computrition, Inc.
175 Middlesex Turnpike
Bedford, MA 01730
ph: 781-275-4488 x5013
fax: 781-357-4100


From: manik sheeri [mailto:she...@gm...]
Sent: Wednesday, February 05, 2014 6:02 AM
To: val...@li...
Subject: [Valgrind-users] unable to start child application

Hi,

I have an application which is started by a shell script.
But before that application is forked , there are many daemon processes started by the start shell script.

Unfortunately, when I use valgrind to initiate the start script with "--trace-children" enabled, the script exits at some point while starting a particular daemon.

My question is, can I simply give my interested executable in the command line, so that valgrind run everything smoothly but only instruments the given executable of interest. ???

thanks,
sheeri

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email

[Valgrind-users] unable to start child application

[manik s. <she...@gm...>]

Hi,

I have an application which is started by a shell script.
But before that application is forked , there are many daemon processes
started by the start shell script.

Unfortunately, when I use valgrind to initiate the start script with
"--trace-children" enabled, the script exits at some point while starting a
particular daemon.

My question is, can I simply give my interested executable in the command
line, so that valgrind run everything smoothly but only instruments the
given executable of interest. ???

thanks,
sheeri

[Valgrind-users] i386 memory fence from libev

[Sean M. <se...@ro...>]

Hi all,

I'm trying to decide if a valgrind warning is a false positive or not.

The code comes from libev's memory fence implementation and reduces to:

-------------------------------------
#include <stdio.h>

int main (void)
{
#if __i386 || __i386__

	printf ("hello 32 bit world \n");
	__asm__ __volatile__ ("lock; orb $0, -1(%%esp)" : : : "memory");
	printf ("goodbye 32 bit world \n");

#endif

	return 0;
}
-------------------------------------

valgrind 3.9.0 complains (on linux, in i386 only of course):

"Invalid read of size 1"
"Address 0x4f760ff is just below the stack ptr."

The libev author believes it is a false positive from valgrind:

<http://lists.schmorp.de/pipermail/libev/2013q2/002173.html>

I've searched the valgrind bug list, but can't seem to find anything related.  I don't really know Intel assembly, but I guess that's doing an OR of constant zero and one byte away from the stack pointer.  Seems dubious to me.

Anyone have thoughts on the snippet's correctness?  Is valgrind indeed wrong to complain?

Thanks,

-- 
____________________________________________________________
Sean McBride, B. Eng                 se...@ro...
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montréal, Québec, Canada

Re: [Valgrind-users] Unrecognised instruction at address

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

On 04/02/14 11:03, Vivek Sundararajan wrote:

> Below is the output I get stating "unhandled instruction".
> Is this because of depending on libraries that are not build with the
> above flags?

It's the AESKEYGENASSIST instruction which, like most of the more recent 
instructions, is only supported in 64 bit mode at the moment and you are 
trying to use it in 32 bit code.

In https://bugs.kde.org/show_bug.cgi?id=296577 Julian commented:

 > This is AESKEYGENASSIST, which is supported in 64 bit mode but not 32
 > bit. Realistically I don't think it will get supported in 32 bit mode
 > -- that doesn't support anything after SSSE3. Can you develop in 64
 > bit mode instead? The main support emphasis now is x86_64 (64 bit)
 > and ARM; x86 (32 bit) is more-or-less "legacy".

Note that the bug I reference above is a bit confused because somebody 
raised it about one instruction and then somebody else added a comment 
about a different instruction.

Tom

-- 
Tom Hughes (to...@co...)
http://compton.nu/

[Valgrind-users] Unrecognised instruction at address

[Vivek S. <s.v...@gm...>]

Hi All,

This is my first post at Valgrind.

I am using valgrind memory check against a C++ client appliction build
using CEF and Qt. I have build my client applicaiton using -O0 -O1 -g
compiler flags. But the external libraries that I use, are not built using
these flags.

Below is the output I get stating "unhandled instruction".
Is this because of depending on libraries that are not build with the above
flags?

Can you please suggest some pointers on going around with this error.

--31825--
/System/Library/PrivateFrameworks/AppleScript.framework/Versions/A/AppleScript
(rx at 0x15802000, rw at 0x15896000)
--31825--    reading syms   from primary file (4 1771)
--31825--
/System/Library/Components/AppleScript.component/Contents/MacOS/AppleScript
(rx at 0x100a0000, rw at 0x100a1000)
--31825--    reading syms   from primary file (3 1)
vex x86->IR: unhandled instruction bytes: 0x66 0xF 0x3A 0xDF
==31825== valgrind: Unrecognised instruction at address 0x803ce41.
==31825==    at 0x803CE41: aes_encrypt_key_hw (in
/usr/lib/system/libcommonCrypto.dylib)
==31825==    by 0x803AC0B: aesedp_setup (in
/usr/lib/system/libcommonCrypto.dylib)
==31825==    by 0x8034F52: cbc_start (in
/usr/lib/system/libcommonCrypto.dylib)
==31825==    by 0x8037811: CCCryptorCreateFromDataWithMode (in
/usr/lib/system/libcommonCrypto.dylib)
==31825==    by 0x80379BA: CCCryptorCreateFromData (in
/usr/lib/system/libcommonCrypto.dylib)
==31825==    by 0x8037116: CCCryptorCreate (in
/usr/lib/system/libcommonCrypto.dylib)
==31825==    by 0x8038011: CCCrypt (in
/usr/lib/system/libcommonCrypto.dylib)
==31825==    by 0x4B13ED1: ??? (in
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
==31825==    by 0x4B13D9C: ??? (in
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
==31825==    by 0x4B13B0C: ??? (in
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
==31825==    by 0x4AE4CDC: ??? (in
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
==31825==    by 0x4AE4A59: ??? (in
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit)
==31825== Your program just tried to execute an instruction that Valgrind
==31825== did not recognise.  There are two possible reasons for this.
==31825== 1. Your program has a bug and erroneously jumped to a non-code
==31825==    location.  If you are running Memcheck and you just saw a
==31825==    warning about a bad jump, it's probably your program's fault.
==31825== 2. The instruction is legitimate but Valgrind doesn't handle it,
==31825==    i.e. it's Valgrind's fault.  If you think this is the case or
==31825==    you are not sure, please let us know and we'll try to fix it.
==31825== Either way, Valgrind will now raise a SIGILL signal which will
==31825== probably kill your program.
==31825==


-- 
Thanks in Advance!
Vivek.S

Re: [Valgrind-users] Memcheck in Valgrind 3.8.1 hanging

[David C. <dc...@gm...>]

Thank you again, Philippe. I will make some investigations next week and
report back.

Regards,
David.

On Friday, January 31, 2014, Philippe Waroquiers <
phi...@sk...> wrote:

> On Fri, 2014-01-31 at 16:34 +0000, David Carter wrote:
> Hello David,
>
> > Hi Philippe,
> >
> >
> >
> > Upgraded to 3.9.0 as you suggested and ran with these options:
> >
> >
> >
> >                 -v -v -v -d -d -d --trace-sched=yes
> > --trace-syscalls=yes --trace-signals=yes --quiet --track-origins=yes
> > --free-fill=7a --child-silent-after-fork=yes --fair-sched=no
> >
> >
> >
> > After some time, a bunch of processes went into 'pipe_w' status.
> > These were single-threaded processes.  Their logfiles (which were
> > enormous - hundreds of gigabytes!) all contained this line:
> >
> >
> >
> >                 --23014--   SCHED[3]: TRC: YIELD
> The above trace is strange: the SCHED[3] indicates that this is
> valgrind thread id 3 which is doing the trace. That seems to indicate
> that there was (at least at some point in time) more than one thread
> in the game.
> The YIELD scheduler trace is explained as:
>       case VEX_TRC_JMP_YIELD:
>          /* Explicit yield, because this thread is in a spin-lock
>             or something.  Only let the thread run for a short while
>             longer.  Because swapping to another thread is expensive,
>             we're prepared to let this thread eat a little more CPU
>             before swapping to another.  That means that short term
>             spins waiting for hardware to poke memory won't cause a
>             thread swap. */
>          if (dispatch_ctr > 1000)
>             dispatch_ctr = 1000;
>          break;
>
>
> >
> >
> >
> > Each of the processes showed only one thread:
> I have already seen in the past that GDB is not always
> able to show the various threads (not clear when, I suspect
> this might happen with a static thread lib ?).
>
> To double check the nr of threads, you can do one of the following:
>    from the shell:
>        vgdb -l
> and then for each reported PIDNR:
>        vgdb --pid=<PIDNR> v.info scheduler
> That will show the state of the valgrind scheduler, and the list
> of threads known by valgrind, and ask valgrind to produce a stack
> trace (guest stack trace) for each thread.
>
> Or alternatively:
>        ls /proc/<PIDNR>/task
> will show the list of threads nr at linux level.
>
>
> >                 #3  0x00000000380daa98 in vgModuleLocal_sema_down
> > (sema=0x802001830, as_LL=0 '\000') at m_scheduler/sema.c:109
> >
> >                 #4  0x0000000038083687 in vgPlain_acquire_BigLock_LL
> > (tid=1, who=0x80956dde0 "") at m_scheduler/scheduler.c:355
> >
> >                 #5  vgPlain_acquire_BigLock (tid=1, who=0x80956dde0
> > "") at m_scheduler/scheduler.c:277
> The above indicates that the thread is trying to acquire the
> valgrind "big lock". When using --fair-sched=no, the big lock is
> implemented using a pipe. Writing a character on the pipe releases
> the lock. Reading the character on the pipe is the lock acquisition.
> If the process is blocked on reading on the pipe, then it looks
> like the "lock" character was not written back ?
> Maybe strace -f valgrind and see what is happening with the lock
> character. The lock character loops over A .. Z and then back to A.
> Check that the lock is properly released some short time before
> the trial to re-acquire it.
>
> >
> >
> > strace showed the same as before (i.e. read on a high-numbered
> > filehandle, around 1026 or 1027).  Someone has suggested that this
> > would indicate that valgrind is calling dup2 to create new
> > filehandles.  Evidence from lsof also bears this out, showing only 77
> > open files for each process.  The fd's not relevant to our application
> > are:
> In the below, I guess that 1028 and 1029 is the pipe used for the
> valgrind lock.
>
> >
> >
> >
> >                 COMMAND    PID    USER   FD   TYPE DEVICE        SIZE
> > NODE NAME
> >
> >                 memcheck- 2071 nbezj7v    5r  FIFO    0,6
> > 297571407 pipe
> >
> >                 memcheck- 2071 nbezj7v    7u  sock    0,5
> > 297780139 can't identify protocol
> >
> >                 memcheck- 2071 nbezj7v    8w  FIFO    0,6
> > 297571410 pipe
> >
> >                 memcheck- 2071 nbezj7v    9r   CHR    1,3
> > 3908 /dev/null
> >
> >                 memcheck- 2071 nbezj7v   10r   DIR  253,0        4096
> > 2 /
> >
> >                 memcheck- 2071 nbezj7v 1025u   REG  253,0         637
> > 1114475 /tmp/valgrind_proc_2071_cmdline_ad8659c2 (deleted)
> >
> >                 memcheck- 2071 nbezj7v 1026u   REG  253,0         256
> > 1114491 /tmp/valgrind_proc_2071_auxv_ad8659c2 (deleted)
> >
> >                 memcheck- 2071 nbezj7v 1028r  FIFO    0,6
> > 297571563 pipe
> >
> >                 memcheck- 2071 nbezj7v 1029w  FIFO    0,6
> > 297571563 pipe
> >
> >                 memcheck- 2071 nbezj7v 1030r  FIFO  253,0
> > 1114706 /tmp/vgdb-pipe-from-vgdb-to-2071-by-USERNAME-on-???
> >
> >
> >
> > I tried vgdb, but not a lot of luck.  After invoking 'valgrind
> > --vgdb=yes --vgdb-error=0 /path/to/my/exe', I then got this in another
> > terminal:
> >
> >
> >
> >                 $ gdb /path/to/my/exe
>
> >                 "/path/to/my/exe": not in executable format: File
> > truncated
> >
> >                 (gdb) target remote
> > | /apps1/pkgs/valgrind-3.9.0/bin/vgdb --pid=30352
> >
> >                 Remote debugging using
> > | /apps1/pkgs/valgrind-3.9.0/bin/vgdb --pid=30352
> >
> >                 relaying data between gdb and process 30352
> >
> >                 Remote register badly formatted:
> >
> T0506:0000000000000000;07:30f0fffe0f000000;10:700aa05d38000000;thread:7690;
> >
> >                 here:
> > 00000000;07:30f0fffe0f000000;10:700aa05d38000000;thread:7690;
> >
> >                 Try to load the executable by `file' first,
> >
> >                 you may also check `set/show architecture'.
> >
> >
> >
> > This also caused the vgdb server to hang up.  I tried with the 'file'
> > command made no difference.  The "not in executable format" is totally
> > expected - we run a optimised lightweight "test shell" process which
> > loads a bunch of heavy debug so's.
> The "not in executable format" is not expected by me :).
>
> What kind of executable is that ? I thought that gdb should be able
> to "understand" the executables that are launchable on e.g. red hat 5
> (if I guessed the distro properly).
>
> In the shell, what is 'file /path/to/my/exe' telling ?
>
> Maybe you could download and compile the last gdb version (7.6 or 7.7
> if it has just been produced) and see if gdb is now more intelligent ?
> >
> >
> >
> > What is the next stage, can I try different options? Or perhaps
> > instrument/change the source code in some way in order to figure out
> > what is happening?
>
> As detailed above, you could:
>   * confirm the list of threads in your process
>      (ls /proc/..., vgdb v.info scheduler)
>   * if v.info scheduler works, you might guess what your
>     application is doing from the stack trace(s)
>   * maybe you could debug using a newer gdb
>   * strace -f valgrind .... /path/to/my/exe
>     might also give some lights on what happens with the valgrind big
>     lock.
>
> Philippe
>
>
>
>

Re: [Valgrind-users] valgrind porting in real time OS

[Philippe W. <phi...@sk...>]

On Thu, 2014-01-30 at 10:52 +0000, Sweta Ruhela wrote:
> Hi,
> 
>  
> 
> I have a great interest in using valgrind with my real time OS on ARM
> based board.
> 
>  
> 
> I have a question that can valgrind be ported on freeRTOS?
> 
>  
> 
> If yes then how much effort will be required and what need to do for
> that task implementation?
> 
>  
> 
> I appreciate for any help in this requirement phase.

There was a recent discussion on porting Valgrind to GNU hurd.
If you go to fosdem, there will
be a presentation about porting valgrind to solaris in the valgrind
devroom.
Let's hope we will have enough volunteers/courage/... to record
the valgrind dev room talks :)

To my knowledge, the source of information for what to do to
port valgrind to a new os is the sources.

Not knowing freeRTOS, I have no idea about the specific difficulties
on this OS compated to a more "classical" environment (such as linux,
android, solaris or freebsd, or darwin).
But even on such classical environments, the porting work is very
 significant.

Philippe

Re: [Valgrind-users] Memcheck in Valgrind 3.8.1 hanging

[Philippe W. <phi...@sk...>]

On Fri, 2014-01-31 at 16:34 +0000, David Carter wrote:
Hello David,

> Hi Philippe,
> 
>  
> 
> Upgraded to 3.9.0 as you suggested and ran with these options:
> 
>  
> 
>                 -v -v -v -d -d -d --trace-sched=yes
> --trace-syscalls=yes --trace-signals=yes --quiet --track-origins=yes
> --free-fill=7a --child-silent-after-fork=yes --fair-sched=no
> 
>  
> 
> After some time, a bunch of processes went into 'pipe_w' status.
> These were single-threaded processes.  Their logfiles (which were
> enormous - hundreds of gigabytes!) all contained this line:
> 
>  
> 
>                 --23014--   SCHED[3]: TRC: YIELD
The above trace is strange: the SCHED[3] indicates that this is
valgrind thread id 3 which is doing the trace. That seems to indicate
that there was (at least at some point in time) more than one thread
in the game.
The YIELD scheduler trace is explained as:
      case VEX_TRC_JMP_YIELD:
	 /* Explicit yield, because this thread is in a spin-lock
	    or something.  Only let the thread run for a short while
            longer.  Because swapping to another thread is expensive,
            we're prepared to let this thread eat a little more CPU
            before swapping to another.  That means that short term
            spins waiting for hardware to poke memory won't cause a
            thread swap. */
	 if (dispatch_ctr > 1000) 
            dispatch_ctr = 1000;
	 break;


> 
>  
> 
> Each of the processes showed only one thread:
I have already seen in the past that GDB is not always
able to show the various threads (not clear when, I suspect
this might happen with a static thread lib ?).

To double check the nr of threads, you can do one of the following:
   from the shell:
       vgdb -l
and then for each reported PIDNR:
       vgdb --pid=<PIDNR> v.info scheduler
That will show the state of the valgrind scheduler, and the list
of threads known by valgrind, and ask valgrind to produce a stack
trace (guest stack trace) for each thread.

Or alternatively:
       ls /proc/<PIDNR>/task
will show the list of threads nr at linux level.


>                 #3  0x00000000380daa98 in vgModuleLocal_sema_down
> (sema=0x802001830, as_LL=0 '\000') at m_scheduler/sema.c:109
> 
>                 #4  0x0000000038083687 in vgPlain_acquire_BigLock_LL
> (tid=1, who=0x80956dde0 "") at m_scheduler/scheduler.c:355
> 
>                 #5  vgPlain_acquire_BigLock (tid=1, who=0x80956dde0
> "") at m_scheduler/scheduler.c:277
The above indicates that the thread is trying to acquire the
valgrind "big lock". When using --fair-sched=no, the big lock is
implemented using a pipe. Writing a character on the pipe releases
the lock. Reading the character on the pipe is the lock acquisition.
If the process is blocked on reading on the pipe, then it looks
like the "lock" character was not written back ?
Maybe strace -f valgrind and see what is happening with the lock
character. The lock character loops over A .. Z and then back to A.
Check that the lock is properly released some short time before
the trial to re-acquire it.

>  
> 
> strace showed the same as before (i.e. read on a high-numbered
> filehandle, around 1026 or 1027).  Someone has suggested that this
> would indicate that valgrind is calling dup2 to create new
> filehandles.  Evidence from lsof also bears this out, showing only 77
> open files for each process.  The fd's not relevant to our application
> are:
In the below, I guess that 1028 and 1029 is the pipe used for the
valgrind lock.

> 
>  
> 
>                 COMMAND    PID    USER   FD   TYPE DEVICE        SIZE
> NODE NAME
> 
>                 memcheck- 2071 nbezj7v    5r  FIFO    0,6
> 297571407 pipe
> 
>                 memcheck- 2071 nbezj7v    7u  sock    0,5
> 297780139 can't identify protocol
> 
>                 memcheck- 2071 nbezj7v    8w  FIFO    0,6
> 297571410 pipe
> 
>                 memcheck- 2071 nbezj7v    9r   CHR    1,3
> 3908 /dev/null
> 
>                 memcheck- 2071 nbezj7v   10r   DIR  253,0        4096
> 2 /
> 
>                 memcheck- 2071 nbezj7v 1025u   REG  253,0         637
> 1114475 /tmp/valgrind_proc_2071_cmdline_ad8659c2 (deleted)
> 
>                 memcheck- 2071 nbezj7v 1026u   REG  253,0         256
> 1114491 /tmp/valgrind_proc_2071_auxv_ad8659c2 (deleted)
> 
>                 memcheck- 2071 nbezj7v 1028r  FIFO    0,6
> 297571563 pipe
> 
>                 memcheck- 2071 nbezj7v 1029w  FIFO    0,6
> 297571563 pipe
> 
>                 memcheck- 2071 nbezj7v 1030r  FIFO  253,0
> 1114706 /tmp/vgdb-pipe-from-vgdb-to-2071-by-USERNAME-on-???
> 
>  
> 
> I tried vgdb, but not a lot of luck.  After invoking 'valgrind
> --vgdb=yes --vgdb-error=0 /path/to/my/exe', I then got this in another
> terminal:
> 
>  
> 
>                 $ gdb /path/to/my/exe

>                 "/path/to/my/exe": not in executable format: File
> truncated
> 
>                 (gdb) target remote
> | /apps1/pkgs/valgrind-3.9.0/bin/vgdb --pid=30352
> 
>                 Remote debugging using
> | /apps1/pkgs/valgrind-3.9.0/bin/vgdb --pid=30352
> 
>                 relaying data between gdb and process 30352
> 
>                 Remote register badly formatted:
> T0506:0000000000000000;07:30f0fffe0f000000;10:700aa05d38000000;thread:7690;
> 
>                 here:
> 00000000;07:30f0fffe0f000000;10:700aa05d38000000;thread:7690;
> 
>                 Try to load the executable by `file' first,
> 
>                 you may also check `set/show architecture'.
> 
>  
> 
> This also caused the vgdb server to hang up.  I tried with the 'file'
> command made no difference.  The "not in executable format" is totally
> expected - we run a optimised lightweight "test shell" process which
> loads a bunch of heavy debug so's.
The "not in executable format" is not expected by me :).

What kind of executable is that ? I thought that gdb should be able
to "understand" the executables that are launchable on e.g. red hat 5
(if I guessed the distro properly).

In the shell, what is 'file /path/to/my/exe' telling ?

Maybe you could download and compile the last gdb version (7.6 or 7.7
if it has just been produced) and see if gdb is now more intelligent ?
> 
>  
> 
> What is the next stage, can I try different options? Or perhaps
> instrument/change the source code in some way in order to figure out
> what is happening?

As detailed above, you could:
  * confirm the list of threads in your process
     (ls /proc/..., vgdb v.info scheduler)
  * if v.info scheduler works, you might guess what your
    application is doing from the stack trace(s)
  * maybe you could debug using a newer gdb
  * strace -f valgrind .... /path/to/my/exe
    might also give some lights on what happens with the valgrind big
    lock.

Philippe 

Re: [Valgrind-users] Memcheck in Valgrind 3.8.1 hanging

[David C. <dc...@gm...>]

Hi Philippe,



Upgraded to 3.9.0 as you suggested and ran with these options:



                -v -v -v -d -d -d --trace-sched=yes --trace-syscalls=yes
--trace-signals=yes --quiet --track-origins=yes --free-fill=7a
--child-silent-after-fork=yes --fair-sched=no



After some time, a bunch of processes went into 'pipe_w' status.  These
were single-threaded processes.  Their logfiles (which were enormous -
hundreds of gigabytes!) all contained this line:



                --23014--   SCHED[3]: TRC: YIELD



Each of the processes showed only one thread:



                GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.1)

                Copyright (C) 2009 Free Software Foundation, Inc.

                License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html>

                This is free software: you are free to change and
redistribute it.

                There is NO WARRANTY, to the extent permitted by law.  Type
"show copying"

                and "show warranty" for details.

                This GDB was configured as "x86_64-redhat-linux-gnu".

                For bug reporting instructions, please see:

                <http://www.gnu.org/software/gdb/bugs/>.

                Attaching to process 2071

                Reading symbols from
/apps1/pkgs/valgrind-3.9.0/lib/valgrind/memcheck-amd64-linux...done.

                0x000000003804b559 in do_syscall_WRK ()

                (gdb) where

                #0  0x000000003804b559 in do_syscall_WRK ()

                #1  0x000000003804b94a in vgPlain_do_syscall (sysno=1028,
a1=34516426208, a2=1, a3=18446744073709551615, a4=0, a5=0, a6=0, a7=0,
a8=0) at m_syscall.c:674

                #2  0x0000000038035d44 in vgPlain_read (fd=1,
buf=0xffffffffffffffff, count=<value optimized out>) at m_libcfile.c:158

                #3  0x00000000380daa98 in vgModuleLocal_sema_down
(sema=0x802001830, as_LL=0 '\000') at m_scheduler/sema.c:109

                #4  0x0000000038083687 in vgPlain_acquire_BigLock_LL
(tid=1, who=0x80956dde0 "") at m_scheduler/scheduler.c:355

                #5  vgPlain_acquire_BigLock (tid=1, who=0x80956dde0 "") at
m_scheduler/scheduler.c:277

                #6  0x00000000380838f5 in vgPlain_scheduler (tid=<value
optimized out>) at m_scheduler/scheduler.c:1227

                #7  0x00000000380b28b6 in thread_wrapper (tidW=1) at
m_syswrap/syswrap-linux.c:103

                #8  run_a_thread_NORETURN (tidW=1) at
m_syswrap/syswrap-linux.c:156

                #9  0x0000000000000000 in ?? ()

                (gdb) info threads

                * 1 process 2071  0x000000003804b559 in do_syscall_WRK ()

                (gdb)



strace showed the same as before (i.e. read on a high-numbered filehandle,
around 1026 or 1027).  Someone has suggested that this would indicate that
valgrind is calling dup2 to create new filehandles.  Evidence from lsof
also bears this out, showing only 77 open files for each process.  The fd's
not relevant to our application are:



                COMMAND    PID    USER   FD   TYPE DEVICE        SIZE
NODE NAME

                memcheck- 2071 nbezj7v    5r  FIFO    0,6
297571407 pipe

                memcheck- 2071 nbezj7v    7u  sock    0,5
297780139 can't identify protocol

                memcheck- 2071 nbezj7v    8w  FIFO    0,6
297571410 pipe

                memcheck- 2071 nbezj7v    9r   CHR    1,3
3908 /dev/null

                memcheck- 2071 nbezj7v   10r   DIR  253,0
4096         2 /

                memcheck- 2071 nbezj7v 1025u   REG  253,0         637
1114475 /tmp/valgrind_proc_2071_cmdline_ad8659c2 (deleted)

                memcheck- 2071 nbezj7v 1026u   REG  253,0         256
1114491 /tmp/valgrind_proc_2071_auxv_ad8659c2 (deleted)

                memcheck- 2071 nbezj7v 1028r  FIFO    0,6
297571563 pipe

                memcheck- 2071 nbezj7v 1029w  FIFO    0,6
297571563 pipe

                memcheck- 2071 nbezj7v 1030r  FIFO  253,0
1114706 /tmp/vgdb-pipe-from-vgdb-to-2071-by-USERNAME-on-???



I tried vgdb, but not a lot of luck.  After invoking 'valgrind --vgdb=yes
--vgdb-error=0 /path/to/my/exe', I then got this in another terminal:



                $ gdb /path/to/my/exe

                GNU gdb (GDB) Red Hat Enterprise Linux (7.0.1-23.el5_5.1)

                Copyright (C) 2009 Free Software Foundation, Inc.

                License GPLv3+: GNU GPL version 3 or later <
http://gnu.org/licenses/gpl.html>

                This is free software: you are free to change and
redistribute it.

                There is NO WARRANTY, to the extent permitted by law.  Type
"show copying"

                and "show warranty" for details.

                This GDB was configured as "x86_64-redhat-linux-gnu".

                For bug reporting instructions, please see:

                <http://www.gnu.org/software/gdb/bugs/>...

                "/path/to/my/exe": not in executable format: File truncated

                (gdb) target remote | /apps1/pkgs/valgrind-3.9.0/bin/vgdb
--pid=30352

                Remote debugging using |
/apps1/pkgs/valgrind-3.9.0/bin/vgdb --pid=30352

                relaying data between gdb and process 30352

                Remote register badly formatted:
T0506:0000000000000000;07:30f0fffe0f000000;10:700aa05d38000000;thread:7690;

                here:
00000000;07:30f0fffe0f000000;10:700aa05d38000000;thread:7690;

                Try to load the executable by `file' first,

                you may also check `set/show architecture'.



This also caused the vgdb server to hang up.  I tried with the 'file'
command made no difference.  The "not in executable format" is totally
expected - we run a optimised lightweight "test shell" process which loads
a bunch of heavy debug so's.



What is the next stage, can I try different options? Or perhaps
instrument/change the source code in some way in order to figure out what
is happening?



Thanks,

David.
------------------------------


On Sunday, January 26, 2014, David Carter <dc...@gm...> wrote:

> Thank you very much, Philippe,
>
> The --fair-sched option was set in an attempt to fix this.  I had read
> about interminable FUTEX_WAIT status and I think that was one of the
> suggestions.  Clearly it doesn't make any difference.
>
> I think I've tried 3.9.0, but I will double-check and run that one from
> now on anyway.
>
> I have tried connecting with gdb and there wasn't much visible. I'll try
> again though and also try vgdb - I was unaware of this tool.
>
> Not sure what is getting locked, whether it's Valgrind or our code.  We do
> use threading but only in a limited way, and I'm pretty sure memcheck is
> hanging up on single-threaded cases.  Hopefully the extra logging etc will
> reveal something. I can't easily log onto the machine from here - I'll run
> the experiments you suggest and report back in a short while.
>
> One thing I didn't mention, which might be important, is that I run
> valgrind through a python-driven process-pool.  I use the multiprocess
> module to spawn off a bunch of valgrinds.  I don't think its relevant as it
> was working fine for several weeks like this before the hang-ups started.
>
> Best wishes and thanks again,
> David.
>
>
>
> On Sun, Jan 26, 2014 at 1:07 PM, Philippe Waroquiers <
> phi...@sk...<javascript:_e(%7B%7D,'cvml','phi...@sk...');>
> > wrote:
>
>> On Sun, 2014-01-26 at 02:20 +0000, David Carter wrote:
>> > Hi,
>> >
>> >
>> > I've got an issue with memcheck in Valgrind 3.8.1 hanging.  I've left
>> > processes running for weeks or even months but they don't complete
>> > (normally these processes run in a few minutes tops, and they were
>> > working fine with memcheck until a while ago.
>> >
>> >
>> > Has anyone seen anything like this before?  Here are the details:
>> >
>> >
>> > options:
>> >
>> > --quiet --track-origins=yes --free-fill=7a
>> > --child-silent-after-fork=yes --fair-sched=no --log-file=/path/to/log
>> >  --suppressions=/path/to/suppression.file
>> >
>> >
>> >
>> > strace shows:
>> >
>> > Process 5223 attached - interrupt to quit
>> >
>> > read(1027,
>> With --fair-sched=no, valgrind uses a pipe to implement a "big lock".
>> It is however not clear with what you have shown if this 1027 is
>> the valgrind pipe big lock fd. If yes, then it looks like a bug in
>> valgrind, as the above read means a thread want to acquire the big
>> lock to run, but the thread currently holding the lock does not
>> release it.
>>
>> Here are various suggestions :
>> 1. when you are in the above blocked state, use gdb+vgdb
>>    to connect to your process, and examine the state
>>    of your process (e.g. which thread is doing what)
>>    (the most likely cause of deadlock/problem is your application, not
>>    valgrind, at least when looking at your mail with
>>    a "valgrind developer hat on" :).
>>
>> 2. upgrade to 3.9.0, there are many bugs solved since 3.8.1
>>    (probably not yours, I do not see anything related to deadlock
>>     but one never knows).
>>
>> 3. run with a lot more traces e.g.
>>     -v -v -v -d -d -d --trace-sched=yes --trace-syscalls=yes
>> --trace-signals=yes
>>   and see if there is some suspicious output.
>>
>> Philippe
>>
>>
>>
>>
>

[Valgrind-users] valgrind porting in real time OS

[Sweta R. <sw...@hc...>]

Hi,

I have a great interest in using valgrind with my real time OS on ARM based board.

I have a question that can valgrind be ported on freeRTOS?

If yes then how much effort will be required and what need to do for that task implementation?

I appreciate for any help in this requirement phase.

Thank you


Regards,
Sweta Ruhela


::DISCLAIMER::
----------------------------------------------------------------------------------------------------------------------------------------------------

The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only.
E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents
(with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates.
Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the
views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of this message without the prior written consent of authorized representative of
HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.
Before opening any email and/or attachments, please check them for viruses and other defects.

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

[Valgrind-users] pthread_key_create() and friends supported by valgrind?

[Tina H. <tin...@gm...>]

Is there any reason why pthread_key_create() should not work with valgrind?

Tina
-- 
Tina Harriott  - Women in Mathematics
Contact: tin...@gm...

Re: [Valgrind-users] valgrind breaks any long double operation on x86-64

[Tina H. <tin...@gm...>]

On 22 January 2014 22:36, Philippe Waroquiers
<phi...@sk...> wrote:
> On Wed, 2014-01-22 at 00:19 +0100, Lionel Cons wrote:
>> On 22 January 2014 00:03, Tom Hughes <to...@co...> wrote:
>> > On 21/01/14 21:49, Tina Harriott wrote:
>> >
>> >> I am new to this list. Can anyone guide me dissect a problem with
>> >> valgrinds long double fp math on x86-64 cpus? We're getting major
>> >> malfunctions in our applications because any long double operation
>> >> (say y=sinl(x)) contains rubbish in the least significant bits.
>> >
>> > See the "Limitations" section of the manual:
>> >
>> >    http://www.valgrind.org/docs/manual/manual-core.html#manual-core.limits
>> >
>> > Specifically the section about floating point limitations.
>>
>> "...Whether or not this is critical remains to be seen..."
>>
>> Yeah, that comment is so 'funny' that it hurts again. The difference
>> between 64bit math and 80bit math is whether a MBDA Meteor missile
>> will hit its target or not (Michael Östergren holds a personal grudge
>> against valgrind because of weeks lost due this particular
>> embarrassing bug screwing up simulations btw), whether the beams in
>> LHC will meet the (intended!) target or not, whether math in SAS
>> software works or not (warranting a warning in the written
>> documentation that running with valgrind to test 3rd party plugins is
>> not supported). So the list of things which do *NOT* work with
>> valgrind is *impressive* and hurt high value projects, IMHO warranting
>> at least the removal of that mocking comment "...Whether or not this
>> is critical remains to be seen...". Please.
> Effectively, it looks clear that many applications have problems
> with this aspect. Would be better to rephrase the doc :).
>
> Now, maybe these applications should better be compilable
> with 64 bits floats, and would/should then work properly natively
> and under valgrind.
>
> The gcc documentation says for -mfpmath=sse:
>
>   The resulting code should be considerably faster in the majority of
>   cases and avoid the numerical instability problems of 387 code, but
>   may break some existing code that expects temporaries to be 80
>   bits.
>
> So, you might try to compile your app with the above flag
> (I guess you might need a #ifdef or so to have a typedef that
> is 80 bits without the above, and 64 bits with the above).
>
> But of course, we all agree it would be nice to have 80 bits floats
> properly supported by Valgrind. It is just nobody has time/money/effort
> to spend on that :(.

Kickstarter project maybe?

Tina
-- 
Tina Harriott  - Women in Mathematics
Contact: tin...@gm...

Re: [Valgrind-users] Memcheck in Valgrind 3.8.1 hanging

[David C. <dc...@gm...>]

Thank you very much, Philippe,

The --fair-sched option was set in an attempt to fix this.  I had read
about interminable FUTEX_WAIT status and I think that was one of the
suggestions.  Clearly it doesn't make any difference.

I think I've tried 3.9.0, but I will double-check and run that one from now
on anyway.

I have tried connecting with gdb and there wasn't much visible. I'll try
again though and also try vgdb - I was unaware of this tool.

Not sure what is getting locked, whether it's Valgrind or our code.  We do
use threading but only in a limited way, and I'm pretty sure memcheck is
hanging up on single-threaded cases.  Hopefully the extra logging etc will
reveal something. I can't easily log onto the machine from here - I'll run
the experiments you suggest and report back in a short while.

One thing I didn't mention, which might be important, is that I run
valgrind through a python-driven process-pool.  I use the multiprocess
module to spawn off a bunch of valgrinds.  I don't think its relevant as it
was working fine for several weeks like this before the hang-ups started.

Best wishes and thanks again,
David.



On Sun, Jan 26, 2014 at 1:07 PM, Philippe Waroquiers <
phi...@sk...> wrote:

> On Sun, 2014-01-26 at 02:20 +0000, David Carter wrote:
> > Hi,
> >
> >
> > I've got an issue with memcheck in Valgrind 3.8.1 hanging.  I've left
> > processes running for weeks or even months but they don't complete
> > (normally these processes run in a few minutes tops, and they were
> > working fine with memcheck until a while ago.
> >
> >
> > Has anyone seen anything like this before?  Here are the details:
> >
> >
> > options:
> >
> > --quiet --track-origins=yes --free-fill=7a
> > --child-silent-after-fork=yes --fair-sched=no --log-file=/path/to/log
> >  --suppressions=/path/to/suppression.file
> >
> >
> >
> > strace shows:
> >
> > Process 5223 attached - interrupt to quit
> >
> > read(1027,
> With --fair-sched=no, valgrind uses a pipe to implement a "big lock".
> It is however not clear with what you have shown if this 1027 is
> the valgrind pipe big lock fd. If yes, then it looks like a bug in
> valgrind, as the above read means a thread want to acquire the big
> lock to run, but the thread currently holding the lock does not
> release it.
>
> Here are various suggestions :
> 1. when you are in the above blocked state, use gdb+vgdb
>    to connect to your process, and examine the state
>    of your process (e.g. which thread is doing what)
>    (the most likely cause of deadlock/problem is your application, not
>    valgrind, at least when looking at your mail with
>    a "valgrind developer hat on" :).
>
> 2. upgrade to 3.9.0, there are many bugs solved since 3.8.1
>    (probably not yours, I do not see anything related to deadlock
>     but one never knows).
>
> 3. run with a lot more traces e.g.
>     -v -v -v -d -d -d --trace-sched=yes --trace-syscalls=yes
> --trace-signals=yes
>   and see if there is some suspicious output.
>
> Philippe
>
>
>
>

Re: [Valgrind-users] Memcheck in Valgrind 3.8.1 hanging

[Philippe W. <phi...@sk...>]

On Sun, 2014-01-26 at 02:20 +0000, David Carter wrote:
> Hi,
> 
> 
> I've got an issue with memcheck in Valgrind 3.8.1 hanging.  I've left
> processes running for weeks or even months but they don't complete
> (normally these processes run in a few minutes tops, and they were
> working fine with memcheck until a while ago.
> 
> 
> Has anyone seen anything like this before?  Here are the details:
> 
> 
> options:
> 
> --quiet --track-origins=yes --free-fill=7a
> --child-silent-after-fork=yes --fair-sched=no --log-file=/path/to/log
>  --suppressions=/path/to/suppression.file
> 
>  
> 
> strace shows:
> 
> Process 5223 attached - interrupt to quit
> 
> read(1027,
With --fair-sched=no, valgrind uses a pipe to implement a "big lock".
It is however not clear with what you have shown if this 1027 is
the valgrind pipe big lock fd. If yes, then it looks like a bug in
valgrind, as the above read means a thread want to acquire the big
lock to run, but the thread currently holding the lock does not
release it.

Here are various suggestions :
1. when you are in the above blocked state, use gdb+vgdb
   to connect to your process, and examine the state
   of your process (e.g. which thread is doing what)
   (the most likely cause of deadlock/problem is your application, not
   valgrind, at least when looking at your mail with
   a "valgrind developer hat on" :).

2. upgrade to 3.9.0, there are many bugs solved since 3.8.1
   (probably not yours, I do not see anything related to deadlock
    but one never knows).

3. run with a lot more traces e.g.
    -v -v -v -d -d -d --trace-sched=yes --trace-syscalls=yes --trace-signals=yes
  and see if there is some suspicious output.

Philippe

[Valgrind-users] Memcheck in Valgrind 3.8.1 hanging

[David C. <dc...@gm...>]

Hi,

I've got an issue with memcheck in Valgrind 3.8.1 hanging.  I've left
processes running for weeks or even months but they don't complete
(normally these processes run in a few minutes tops, and they were working
fine with memcheck until a while ago.

Has anyone seen anything like this before?  Here are the details:

options:

--quiet --track-origins=yes --free-fill=7a --child-silent-after-fork=yes
--fair-sched=no --log-file=/path/to/log
 --suppressions=/path/to/suppression.file



strace shows:

Process 5223 attached - interrupt to quit

read(1027,



system details:

$ uname -a

Linux HOSTNAME 2.6.18-194.3.1.el5 #1 SMP Sun May 2 04:17:42 EDT 2010 x86_64
x86_64 x86_64 GNU/Linux



$ cat /etc/redhat-release

Red Hat Enterprise Linux Server release 5.5 (Tikanga)





Top shows:

                732 USER   25   0 2396m 1.6g 110m S 99.8  3.5  86263:19
memcheck-amd64-


25100 USER   25   0 2498m 1.7g 112m S 99.8  3.6  86272:55
memcheck-amd64-



Ps shows pipe wait in WCHAN:

                0 S nbezj7v  25100  1864 98  85   0 - 639685 pipe_w 2013
?        59-22:03:14 /path/to/valgrind options



Have seen it also hang on fast mutexes – i.e. strace/ps will show the
process in FUTEX_WAIT status.

Thanks,
David.