valgrind-users

Re: [Valgrind-users] Unique log filename

[Skarakis, K. <kon...@un...>]

Hi Eliot,



I really appreciate this patch. It's exactly what I was looking for. I must be doing something wrong though. When I apply the patch and try to "make" I get this error:



m_options.c: In function âvgPlain_expand_file_nameâ:

m_options.c:244: warning: assignment discards qualifiers from pointer target type

m_options.c:252: error: assignment of read-only location â*(format + (long unsigned int)(long unsigned int)i)â

m_options.c:253: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness

m_options.c:254: warning: pointer targets in passing argument 1 of âvgPlain_strcpyâ differ in signedness

m_options.c:254: warning: pointer targets in passing argument 2 of âvgPlain_strcpyâ differ in signedness

m_options.c:256: error: assignment of read-only location â*(format + (long unsigned int)(long unsigned int)i)â

m_options.c:279: warning: pointer targets in initialization differ in signedness

m_options.c:279: warning: pointer targets in initialization differ in signedness

m_options.c:280: warning: pointer targets in passing argument 1 of âvgPlain_execvâ differ in signedness

m_options.c:280: warning: passing argument 2 of âvgPlain_execvâ from incompatible pointer type

m_options.c:327: warning: implicit declaration of function âvgPlain_sigemptysetâ

m_options.c:330: warning: implicit declaration of function âvgPlain_sigactionâ

m_options.c:335: warning: implicit declaration of function âvgPlain_convert_sigaction_fromK_to_toKâ

m_options.c:346: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness

m_options.c:346: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness



Line 252 is:

format[i] = 0;

Line 256 is:

      format[i] = '}';





Maybe I didn't apply the patch right...



Kind Regards,

Costas



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



Date: Tue, 23 Sep 2014 14:11:01 -0400

From: Eliot Moss <mo...@cs...<mailto:mo...@cs...>>

Subject: Re: [Valgrind-users] Unique log filename

To: "val...@li...<mailto:val...@li...>"

      <val...@li...<mailto:val...@li...>>

Message-ID: <542...@cs...<mailto:542...@cs...>>

Content-Type: text/plain; charset="windows-1252"



Ok, here's the patch to add the %s{script} form

to log-file expansion.  The script is run via

/bin/bash -c script, and its output replaces the

while %s form.  The max length my code allows

for the result is 500 characters, which seemed

enough for anything realistic.  Note that the

pid of the invoking valgrind will be the script's

PPID, etc.



If the "powers that be" think this might be

generally useful, then let me know how you would

prefer to receive the patch, and any tidying you

feel would be in order ...



Regards -- Eliot Moss

Re: [Valgrind-users] Unique log filename

[Skarakis, K. <kon...@un...>]

That's fantastic. Thank you very much for your time. It works great. 

Here's how I am using it:

I have this line in my ~/.valgrindrc:

--log-file=/software/valgrind/rpts/%s{"/software/dstring"}-%p-report.txt

And these are the contents of /software/dstring:

echo $(ps -f $PPID | tail -n 1 | awk "{print \$10}")-$(date +%Y%m%d%H%M%S%N)

This results in this very nice log:

$ valgrind ls
cap.cap  cov  covfsn  md5r  rpts  rpts1  rpts_fsn_errors

$ ls /software/valgrind/rpts    
ls-20140925123940975544578-18453-report.txt


Kind Regards,
Costas


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

Message: 3
Date: Wed, 24 Sep 2014 09:51:38 -0400
From: Eliot Moss <mo...@cs...>
Subject: Re: [Valgrind-users] Unique log filename
To: "val...@li..."
	<val...@li...>
Message-ID: <542...@cs...>
Content-Type: text/plain; charset="windows-1252"

On 9/24/2014 7:39 AM, Eliot Moss wrote:
> On 9/24/2014 5:31 AM, Skarakis, Konstantinos wrote:

Ok -- I decided to just give it a try in a copy of valgrind updated to svn head.  The issue is that I was temporarily sticking a null character into the format string, yet the format string was declared somewhere else as const.  That declaration was righteous, and my temporary insertion of a null I admit was a hack.  I was already copying the relevant part of the format string out into a temporary buffer, so the actual adjustments needed were small.  Once I made those changes, it compiles and passes check tests for me (on a linux amd64 system).  I attach the updated patch.  I'll see about submitting this, though there also needs to be an update to a section of the manual for a complete patch to make sense for the distro.

Regards -- Eliot Moss

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

On 9/25/2014 5:45 AM, Skarakis, Konstantinos wrote:
> That's fantastic. Thank you very much for your time. It works great.

Good news that it works for someone else too!

I started updating the valgrind documentation to add description
of this new feature, and expect to submit a patch soon for
developer approval.

Regards - Eliot

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

On 9/25/2014 5:45 AM, Skarakis, Konstantinos wrote:
> That's fantastic. Thank you very much for your time. It works great.
>
> Here's how I am using it:
>
> I have this line in my ~/.valgrindrc:
>
> --log-file=/software/valgrind/rpts/%s{"/software/dstring"}-%p-report.txt
>
> And these are the contents of /software/dstring:
>
> echo $(ps -f $PPID | tail -n 1 | awk "{print \$10}")-$(date +%Y%m%d%H%M%S%N)
>
> This results in this very nice log:
>
> $ valgrind ls
> cap.cap  cov  covfsn  md5r  rpts  rpts1  rpts_fsn_errors
>
> $ ls /software/valgrind/rpts
> ls-20140925123940975544578-18453-report.txt
>
>
> Kind Regards,
> Costas

You're welcome!  The use case that prompted me to add the feature was
using lackey to generate full memory access traces from a benchmark that
invoked subprocesses.  The traces are very large, and so I compress them
by piping lackey output to gzip.  This is easy to express for a single
process on the command line, but for dynamically generated subprocesses
I needed to construct a fifo, with gzip on the other end, and return
the path name of the fifo for valgrind to open.  As in your case, worked
great.

Cheers -- E

Re: [Valgrind-users] Unique log filename

[Julian S. <js...@ac...>]

On 09/25/2014 12:52 PM, Eliot Moss wrote:
> I started updating the valgrind documentation to add description
> of this new feature, and expect to submit a patch soon for
> developer approval.

https://bugs.kde.org/show_bug.cgi?id=339405
is the bug, yes?

J

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

On 9/26/2014 12:38 PM, Julian Seward wrote:
> On 09/25/2014 12:52 PM, Eliot Moss wrote:
>> I started updating the valgrind documentation to add description
>> of this new feature, and expect to submit a patch soon for
>> developer approval.
>
> https://bugs.kde.org/show_bug.cgi?id=339405
> is the bug, yes?

Yes, that's the "bug" notice with the patch to add this feature.

Regards -- Eliot

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

On 9/24/2014 5:31 AM, Skarakis, Konstantinos wrote:

> I really appreciate this patch. It’s exactly what I was looking for. I must be doing something wrong
> though. When I apply the patch and try to “make” I get this error:
>
> m_options.c: In function âvgPlain_expand_file_nameâ:
>
> m_options.c:244: warning: assignment discards qualifiers from pointer target type
>
> m_options.c:252: error: assignment of read-only location â*(format + (long unsigned int)(long
> unsigned int)i)â
>
> m_options.c:253: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness
>
> m_options.c:254: warning: pointer targets in passing argument 1 of âvgPlain_strcpyâ differ in signedness
>
> m_options.c:254: warning: pointer targets in passing argument 2 of âvgPlain_strcpyâ differ in signedness
>
> m_options.c:256: error: assignment of read-only location â*(format + (long unsigned int)(long
> unsigned int)i)â
>
> m_options.c:279: warning: pointer targets in initialization differ in signedness
>
> m_options.c:279: warning: pointer targets in initialization differ in signedness
>
> m_options.c:280: warning: pointer targets in passing argument 1 of âvgPlain_execvâ differ in signedness
>
> m_options.c:280: warning: passing argument 2 of âvgPlain_execvâ from incompatible pointer type
>
> m_options.c:327: warning: implicit declaration of function âvgPlain_sigemptysetâ
>
> m_options.c:330: warning: implicit declaration of function âvgPlain_sigactionâ
>
> m_options.c:335: warning: implicit declaration of function âvgPlain_convert_sigaction_fromK_to_toKâ
>
> m_options.c:346: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness
>
> m_options.c:346: warning: pointer targets in passing argument 1 of âvgPlain_strlenâ differ in signedness
>
> Line 252 is:
>
> format[i] = 0;
>
> Line 256 is:
>
>        format[i] = ‘}’;
>
> Maybe I didn’t apply the patch right…

The patch is against a somewhat older version of valgrind, and was also never
tested in other OS environments than my own.  My sense of the above is that
some declarations need adjustment around signed/unsigned and const or not,
or else rather than modifying 'format' in place, the code needs to copy the
relevant part out to a separate string.  Also, some of the routines I called
in the code (execva, sigaction, strlen) seem not to have their proper
declarations available.

I am sure this can all be solved, but I am not sure when I will have time to
work on porting it forward to present day valgrind.

Thoughts from the list?

Regards -- Eliot Moss

Re: [Valgrind-users] Unique log filename

[Eliot M. <mo...@cs...>]

On 9/24/2014 7:39 AM, Eliot Moss wrote:
> On 9/24/2014 5:31 AM, Skarakis, Konstantinos wrote:

Ok -- I decided to just give it a try in a copy of valgrind
updated to svn head.  The issue is that I was temporarily
sticking a null character into the format string, yet the
format string was declared somewhere else as const.  That
declaration was righteous, and my temporary insertion of
a null I admit was a hack.  I was already copying the
relevant part of the format string out into a temporary
buffer, so the actual adjustments needed were small.  Once
I made those changes, it compiles and passes check tests
for me (on a linux amd64 system).  I attach the updated
patch.  I'll see about submitting this, though there also
needs to be an update to a section of the manual for a
complete patch to make sense for the distro.

Regards -- Eliot Moss