valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Can i get a warning to issue the stacktrace?

[Nicholas N. <nj...@ca...>]

On Thu, 1 May 2003, Tom Hughes wrote:

> > I'm getting a few
> >
> > "Warning: src and dst overlap in memcpy (0xblah, 0xblah, a_length)"
> >
> > Is there any way to get valgrind to dump the call stack on this warning
> > like it does on errors so i could see where this is happening?
>
> I happen to have a patch to make it do that that I've been meaning
> to send it. I'm attaching it to this message...

Cool, thanks.  That was on my todo list, you've saved me some time :)
I will commit it some time soon.
(where "two days" < "soon" && "two weeks" < "soon")

N

Re: [Valgrind-users] Can i get a warning to issue the stacktrace?

[Tom H. <th...@cy...>]

In message <29B...@rn...> you wrote:

> I'm getting a few
> 
> "Warning: src and dst overlap in memcpy (0xblah, 0xblah, a_length)"
> 
> Is there any way to get valgrind to dump the call stack on this warning
> like it does on errors so i could see where this is happening?

I happen to have a patch to make it do that that I've been meaning
to send it. I'm attaching it to this message...

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/

[Valgrind-users] Can i get a warning to issue the stacktrace?

[Dilkie, L. <Lee...@mi...>]

I'm getting a few

"Warning: src and dst overlap in memcpy (0xblah, 0xblah, a_length)"

Is there any way to get valgrind to dump the call stack on this warning like it does on errors so i could see where this is happening?

I'm using the latest version, cvs'ed this morning. It solved the seg fault when i tried to run hellgrind on the "official" version but this new warning message is emitted now.

TIA,

-lee

Re: [Valgrind-users] instruction trace

[David B. <dbr...@st...>]

> > I've used vtune to get instructions retired, but that is sort of on the
> > "opposite" end of the processor that I'm interested in.  [snip]
>  > For the paper, I'd like to compare instructions
> > issued vs. instructions retired for the two programs.  On the P4, those
> > two may not be the same for a number of weird P4 reasons (as I
> > understand talking to P4 experts). [snip]
> > I've tried valgrind with --single-step=yes, and see a couple of
> > different things that I think *may* be the instructions issued, like
> > "translate: new" in the output, but I'm not sure.  Is this instructions
> > issued?
> 
> All x86 implementations beginning with the Intel PentiumPro [ca.1995] have
> speculative, out-of-order execution, including along false conditional
> control paths (and even false _un_conditional control paths).  Speculation
> is influenced by code alignment, icache and dcache hits/misses, interrupts
> and task switches, CPU temperature, etc.  "Instructions issued" is almost
> meaningless for the hardware; certainly no software could ever compute it.


Thanks, that's good information but I'm not sure it completely answers
my question.  What I want is the number of assembly instructions issued,
then I can calculate with vtune the number of instructions retired.  It
would be interesting in it's own right just to compare the two...(esp.
since instructions retired is uops, not assembly instructions).  

I was hoping valgrind already would increment an instructions issued
variable before simulating the execution...this is all I really need for
right now.  Is this in the output of valgrind? 

After I get that number, i'll compare it to vtune's instructions retired
(running the program by itself w/o valgrind).

-david

Re: [Valgrind-users] valgrind cvs

[Bastien C. <ba...@ch...>]

On Wednesday 30 April 2003 22:56, Andr=E9s Rold=E1n wrote:
> Hi, this is just a stupid question.
> I'd want to know how can I access the valgrind cvs repository

Does this help? http://sourceforge.net/cvs/?group_id=3D46268
Paragraph "Anonymous CVS Access"

Salut,
    Bastien

=2D-=20
        -- The universe has its own cure for stupidity. --
         -- Unfortunately, it doesn't always apply it. --

Re: [Valgrind-users] instruction trace

[Vimal R. <vim...@ya...>]

I'm sorry, I did'nt pay attention to the x86 part of the message. Shade only
works for Solaris. Sorry abt that.
-vimal

--- Vimal Reddy <vim...@ya...> wrote:
> I used Sun's shade. It's pretty good and also has the option where you can
> choose to trace annulled (squashed) instructions. Which I guess would be the
> same as the number of instructions issued (?).
> The standard download also comes with a program (icount.c) that you can
> easily
> compile and run.
> 
> Hope that helps.
> 
> Thanks,
> Vimal
> 
> 
> --- Nicholas Nethercote <nj...@ca...> wrote:
> > On 29 Apr 2003, David Brumley wrote:
> > 
> > > Is it possible to use valgrind to get a total number of x86 assembly
> > > instructions issued?  Specifically, I'm trying to see how many assembly
> > > instructions are issued for a given input into a crypto library.  I've
> > > looked and used profiling tools such as vtune and got total number of
> > > instructions retired, but that's not quite what I'm interested in.  I
> > > want the total number of assembly instructions given to the processor...
> > 
> > Lackey and Cachegrind (Valgrind skins, use --skin=lackey or
> > --skin=cachegrind in any version later than 1.0.4) both measure x86
> > instructions retired (I think?  I guess so) but not the number issued.
> > 
> > > If not valgrind, does anyone have any suggestions?  I can't find any
> > > good execution tracing tools for x86 and linux....
> > 
> > You want Rabbit: www.scl.ameslab.gov/Projects/Rabbit/.  I've used it lots,
> > it's very good, gives you access to all your machine's performance
> > counters.  I have an Athlon, I know it gives you both instructions issued
> > and retired, I think the Pentium counters probably give you those two.
> > 
> > Or if you have a P4, Brink+Abyss:
> > www.eg.bucknell.edu/~bsprunt/emon/brink_abyss/brink_abyss.shtm.  I haven't
> > tried it, but it looks very powerful.
> > 
> > N
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:ThinkGeek
> > Welcome to geek heaven.
> > http://thinkgeek.com/sf
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> =====
> Vimal Reddy
> Graduate Student, ECE
> North Carolina State University
> Raleigh, NC
> Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy
> 
> __________________________________
> Do you Yahoo!?
> The New Yahoo! Search - Faster. Easier. Bingo.
> http://search.yahoo.com
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users


=====
Vimal Reddy
Graduate Student, ECE
North Carolina State University
Raleigh, NC
Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

[Valgrind-users] valgrind cvs

[<ar...@fl...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, this is just a stupid question.
I'd want to know how can I access the valgrind cvs repository

Thanks in advance

=2D --=20
Andres Roldan, CSO
Fluidsignal Group
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+sDiY2OByS7KTlusRAonzAJ9Y9zMiwTERg2092FYdSGtMZqctmQCfR1UF
ZKoHcLqnbHneq2Em+0aIZgU=3D
=3DakVf
=2D----END PGP SIGNATURE-----

Re: [Valgrind-users] instruction trace

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

David Brumley wrote:
 > [snip]
> I've used vtune to get instructions retired, but that is sort of on the
> "opposite" end of the processor that I'm interested in.  [snip]
 > For the paper, I'd like to compare instructions
> issued vs. instructions retired for the two programs.  On the P4, those
> two may not be the same for a number of weird P4 reasons (as I
> understand talking to P4 experts). [snip]
> I've tried valgrind with --single-step=yes, and see a couple of
> different things that I think *may* be the instructions issued, like
> "translate: new" in the output, but I'm not sure.  Is this instructions
> issued?

All x86 implementations beginning with the Intel PentiumPro [ca.1995] have
speculative, out-of-order execution, including along false conditional
control paths (and even false _un_conditional control paths).  Speculation
is influenced by code alignment, icache and dcache hits/misses, interrupts
and task switches, CPU temperature, etc.  "Instructions issued" is almost
meaningless for the hardware; certainly no software could ever compute it.

-- 
John Reiser, jr...@Bi...

Re: [Valgrind-users] Invalid write of size 4 and ...

[Nicholas N. <nj...@ca...>]

On Wed, 30 Apr 2003, Xiang Yan wrote:

> 1. there is a malloc(24) (// any constant) crashs the app outside
> valgrind, in valgrind however, it's just fine :( . any more clues on
> this?

It's possible your program corrupts some state used by the normal
malloc(), but a different malloc() (such as Valgrind's) doesn't get
corrupted.  If you can find a different malloc() implementation and link
with that (even dynamically with the LD_PRELOAD variable -- see the
'ld.so' man page for details) you might get a different result to the
normal malloc(), which would confirm (I think?) this hypothesis.

N

Re: [Valgrind-users] Error using cachegrind

[Nicholas N. <nj...@ca...>]

On Sun, 27 Apr 2003, Josef Weidendorfer wrote:

> > > Nick, we should add a implementation of getcwd() to V, and use absolute
> > > file paths. But this still doesn't work with chroot() programs :-(

Done: Cachegrind now uses getcwd() at startup and just dumps
cachegrind.out.<pid> in that directory at the end.  Should fix the
problems.  I just committed it to the CVS HEAD.

N

Re: [Valgrind-users] Invalid write of size 4 and ...

[Nicholas N. <nj...@ca...>]

On Wed, 30 Apr 2003, Xiang Yan wrote:

> 2. I have two errors in following oci call:
> ==13548== Thread 4:
> ==13548== Invalid write of size 4
> ==13548==    at 0x81FFE55: kpughndl0 (in..)
> ==13548==    by 0x82071A3: kpughndl (in ..)
> ==13548==    by 0x81DBFBA: kpubndp0 (in ..)
> ==13548==    by 0x8077F74: OCIBindByPos (in .. /* &pocibind[0,1..n-1] as a param of this call*/  )
> ==13548==    Address 0x41B6BA44 is 8 bytes after a block of size 4 alloc'd
> ==13548==    at 0x400485EC: __builtin_vec_new (vg_clientfuncs.c:156)
> ==13548==    by 0x8062AE8: myapp::prepareparams(void) (myapp.cpp:1270 /* OCIBind **pocibind = new OCIBind*[n]; */)
> ...
> Can I have more insight on "Address 0x41B6BA44 is 8 bytes after a block
> of size 4 alloc'd" ?

Your function kpughndl0() accesses the address 0x41B6BA44 which is invalid
-- not addressible.  However, it comes only 8 bytes after the end of a
valid block allocated with new[] in myapp::prepareparams(), so there's a
good chance that you've overrun the end of the block.

N

Re: [Valgrind-users] instruction trace

[Nicholas N. <nj...@ca...>]

On 30 Apr 2003, David Brumley wrote:

> > You want Rabbit: www.scl.ameslab.gov/Projects/Rabbit/.
>
> Thanks, i was aware of those two, but the major drawback for either is
> the need to recompile the source.

You don't need to recompile the source with Rabbit.  You can insert calls
to Rabbit's library if you want to time parts of the program, but you can
just run the program 'rabbit' (which comes from rabbit.c).  By default it
uses sampling to get estimates of all the events your processor can
measure, but if you use the --events option it only measures a small
number (on the Athlon it's 4) of events exactly.

N

Re: [Valgrind-users] instruction trace

[David B. <dbr...@st...>]

> 
> Lackey and Cachegrind (Valgrind skins, use --skin=lackey or
> --skin=cachegrind in any version later than 1.0.4) both measure x86
> instructions retired (I think?  I guess so) but not the number issued.
> 
> > If not valgrind, does anyone have any suggestions?  I can't find any
> > good execution tracing tools for x86 and linux....
> 
> You want Rabbit: www.scl.ameslab.gov/Projects/Rabbit/.  I've used it lots,
> it's very good, gives you access to all your machine's performance
> counters.  I have an Athlon, I know it gives you both instructions issued
> and retired, I think the Pentium counters probably give you those two.
> 
> Or if you have a P4, Brink+Abyss:
> www.eg.bucknell.edu/~bsprunt/emon/brink_abyss/brink_abyss.shtm.  I haven't
> tried it, but it looks very powerful.

Thanks, i was aware of those two, but the major drawback for either is
the need to recompile the source. 

I've used vtune to get instructions retired, but that is sort of on the
"opposite" end of the processor that I'm interested in.  To give you an
idea why i'm asking, here's a short explanation.  I'm developing timing
attacks against OpenSSL
(http://crypto.stanford.edu/~dabo/abstracts/ssl-timing.html).  The
timing characteristics we need are about 1% of the total execution time
(measured in cycles).  I've noticed that a small change in the source,
say one extra mov instruction, will change the function offsets (say
program A without the extra instruction vs. program B with the extra
instruction).  This alignment difference can skew the execution profile
by 1% or a little more, changing the timing attack characteristics
(unfortunately for security people it still works).  Most notably, what
algorithmically should result in say a negative timing difference when a
bit of the key=0 can become a positive timing difference, showing that
the P4's internal optimizations such as branch predictions, etc. can
influence the results.  For the paper, I'd like to compare instructions
issued vs. instructions retired for the two programs.  On the P4, those
two may not be the same for a number of weird P4 reasons (as I
understand talking to P4 experts).  (And yes, I've verified the change
isn't due to a bug in the program by inspecting the assembly output and
checking for memory problems. In the end, I'm hoping to show simpler
processors aren't affected by such small changes in the source, like the
Pentium 2)

So, I can't recompile my two test programs easily, since any change by
adding libraries or external function calls changes the attack
characteristic itself, as explained above. (I'm surprised that this
isn't obviated on the websites for Rabbit and the like...inserting the
code to measure timing can change the timing).

I've tried valgrind with --single-step=yes, and see a couple of
different things that I think *may* be the instructions issued, like
"translate: new" in the output, but I'm not sure.  Is this instructions
issued?

Thanks for everyone's help!
-david

Re: [Valgrind-users] instruction trace

[Vimal R. <vim...@ya...>]

I used Sun's shade. It's pretty good and also has the option where you can
choose to trace annulled (squashed) instructions. Which I guess would be the
same as the number of instructions issued (?).
The standard download also comes with a program (icount.c) that you can easily
compile and run.

Hope that helps.

Thanks,
Vimal


--- Nicholas Nethercote <nj...@ca...> wrote:
> On 29 Apr 2003, David Brumley wrote:
> 
> > Is it possible to use valgrind to get a total number of x86 assembly
> > instructions issued?  Specifically, I'm trying to see how many assembly
> > instructions are issued for a given input into a crypto library.  I've
> > looked and used profiling tools such as vtune and got total number of
> > instructions retired, but that's not quite what I'm interested in.  I
> > want the total number of assembly instructions given to the processor...
> 
> Lackey and Cachegrind (Valgrind skins, use --skin=lackey or
> --skin=cachegrind in any version later than 1.0.4) both measure x86
> instructions retired (I think?  I guess so) but not the number issued.
> 
> > If not valgrind, does anyone have any suggestions?  I can't find any
> > good execution tracing tools for x86 and linux....
> 
> You want Rabbit: www.scl.ameslab.gov/Projects/Rabbit/.  I've used it lots,
> it's very good, gives you access to all your machine's performance
> counters.  I have an Athlon, I know it gives you both instructions issued
> and retired, I think the Pentium counters probably give you those two.
> 
> Or if you have a P4, Brink+Abyss:
> www.eg.bucknell.edu/~bsprunt/emon/brink_abyss/brink_abyss.shtm.  I haven't
> tried it, but it looks very powerful.
> 
> N
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users


=====
Vimal Reddy
Graduate Student, ECE
North Carolina State University
Raleigh, NC
Ph: (919) 836-8254 Web: http://www4.ncsu.edu/~vkreddy

__________________________________
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

[Valgrind-users] Invalid write of size 4 and ...

[Xiang Y. <xy...@pr...>]

Hello,

redhat linux ads/glibc 2.2.4/gcc2.96/pthread
I'm using Oracle call interface apis in my app which is hard for me to =
trace. I have two questions:
1. there is a malloc(24) (// any constant) crashs the app outside =
valgrind, in valgrind however, it's just fine=20
:( . any more clues on this?  =20
2. I have two errors in following oci call:
=3D=3D13548=3D=3D Thread 4:
=3D=3D13548=3D=3D Invalid write of size 4
=3D=3D13548=3D=3D    at 0x81FFE55: kpughndl0 (in..)
=3D=3D13548=3D=3D    by 0x82071A3: kpughndl (in ..)
=3D=3D13548=3D=3D    by 0x81DBFBA: kpubndp0 (in ..)
=3D=3D13548=3D=3D    by 0x8077F74: OCIBindByPos (in .. /* =
&pocibind[0,1..n-1] as a param of this call*/  )
=3D=3D13548=3D=3D    Address 0x41B6BA44 is 8 bytes after a block of size =
4 alloc'd
=3D=3D13548=3D=3D    at 0x400485EC: __builtin_vec_new =
(vg_clientfuncs.c:156)
=3D=3D13548=3D=3D    by 0x8062AE8: myapp::prepareparams(void) =
(myapp.cpp:1270 /* OCIBind **pocibind =3D new OCIBind*[n]; */)
...
Can I have more insight on "Address 0x41B6BA44 is 8 bytes after a block =
of size 4 alloc'd" ?

TIA

Re: [Valgrind-users] Valgrind RH RPM packages for RH62, RH72, RH80 and RH9

[Tom H. <th...@cy...>]

In message <Pin...@ho...>
        Dag Wieers <da...@wi...> wrote:

> PS These packages still have a problem with some private GLIBC symbols 
> that are in the dependencies of the package. I can't seem to fix this by 
> doing:
> 
> 	%define __find_provides() /usr/lib/rpm/find-provides %* | grep -v '^libpthread.so'
> 	%define __find_requires() /usr/lib/rpm/find-requires %* | grep -v 'libc.so.6(GLIBC_PRIVATE)'
> 
> So unless I find a clean way of doing this, you might have to install with 
> --nodeps on some RH's (RH80 and RH73 afaik).

What I do is to add this to the spec file:

  %define __find_requires %{_sourcedir}/valgrind-find-requires

along with a declaration of an extra source file:

  Source1: valgrind-find-requires

The valgrind-find-requires file in my SOURCES directory then looks
like this:

  #!/bin/sh

  /usr/lib/rpm/find-requires "$@" | grep -v GLIBC_PRIVATE

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/

Re: [Valgrind-users] NULL parameters in system calls

[Tom H. <th...@cy...>]

In message <105...@ma...>
        Stephane Donze <ste...@ex...> wrote:

> is it possible to patch the syscall wrappers so that they accept legal
> NULL values in their parameters ? I tried to find out how to do that,
> but I think I need some help to understant the many levels of
> indirections in the wrapper invocation.

This should do the trick:

--- valgrind-20030428/coregrind/vg_syscalls.c.accept	2003-04-30 08:31:09.000000000 +0100
+++ valgrind-20030428/coregrind/vg_syscalls.c	2003-04-30 08:32:02.000000000 +0100
@@ -2949,12 +2949,14 @@
                {
                Addr addr_p     = ((UInt*)arg2)[1];
                Addr addrlen_p  = ((UInt*)arg2)[2];
-               buf_and_len_pre_check ( tst, addr_p, addrlen_p,
-                                       "socketcall.accept(addr)",
-                                       "socketcall.accept(addrlen_in)" );
-               KERNEL_DO_SYSCALL(tid,res);
-               buf_and_len_post_check ( tst, res, addr_p, addrlen_p,
-                                        "socketcall.accept(addrlen_out)" );
+               if (addr_p)
+                  buf_and_len_pre_check ( tst, addr_p, addrlen_p,
+                                          "socketcall.accept(addr)",
+                                          "socketcall.accept(addrlen_in)" );
+               KERNEL_DO_SYSCALL(tid,res);
+               if (addr_p)
+                  buf_and_len_post_check ( tst, res, addr_p, addrlen_p,
+                                           "socketcall.accept(addrlen_out)" );
                }
                break;
             }

Tom

-- 
Tom Hughes (th...@cy...)
Software Engineer, Cyberscience Corporation
http://www.cyberscience.com/

Re: [Valgrind-users] instruction trace

[Nicholas N. <nj...@ca...>]

On 29 Apr 2003, David Brumley wrote:

> Is it possible to use valgrind to get a total number of x86 assembly
> instructions issued?  Specifically, I'm trying to see how many assembly
> instructions are issued for a given input into a crypto library.  I've
> looked and used profiling tools such as vtune and got total number of
> instructions retired, but that's not quite what I'm interested in.  I
> want the total number of assembly instructions given to the processor...

Lackey and Cachegrind (Valgrind skins, use --skin=lackey or
--skin=cachegrind in any version later than 1.0.4) both measure x86
instructions retired (I think?  I guess so) but not the number issued.

> If not valgrind, does anyone have any suggestions?  I can't find any
> good execution tracing tools for x86 and linux....

You want Rabbit: www.scl.ameslab.gov/Projects/Rabbit/.  I've used it lots,
it's very good, gives you access to all your machine's performance
counters.  I have an Athlon, I know it gives you both instructions issued
and retired, I think the Pentium counters probably give you those two.

Or if you have a P4, Brink+Abyss:
www.eg.bucknell.edu/~bsprunt/emon/brink_abyss/brink_abyss.shtm.  I haven't
tried it, but it looks very powerful.

N

[Valgrind-users] NULL parameters in system calls

[Stephane D. <ste...@ex...>]

Hello,

when using the following system call (which is legal, according to the
accept(2) man page), valgrind 1.9.5 complains about the parameters being
NULL:

  for (;;) {
    fd = accept(server, NULL, NULL);
    if (fd != -1) {
      /* Success. */
      break;
    }



==32217== Syscall param socketcall.accept(addrlen_in) contains
uninitialised or 
unaddressable byte(s)
==32217==    at 0x4073ADE6: __libc_accept (in /lib/i686/libc-2.3.1.so)
==32217==    by 0x401755B9: accept (vg_intercept.c:142)
==32217==    by 0x8049B10: (within /tmp/test)
==32217==    Address 0x0 is not stack'd, malloc'd or free'd
==32217== 
==32217== Syscall param socketcall.accept(addrlen_out) contains
uninitialised or
 unaddressable byte(s)
==32217==    at 0x4073ADE6: __libc_accept (in /lib/i686/libc-2.3.1.so)
==32217==    by 0x401755B9: accept (vg_intercept.c:142)
==32217==    by 0x8049B10: (within /tmp/test)
==32217==    Address 0x0 is not stack'd, malloc'd or free'd



is it possible to patch the syscall wrappers so that they accept legal
NULL values in their parameters ? I tried to find out how to do that,
but I think I need some help to understant the many levels of
indirections in the wrapper invocation.

Thanks in advance

Stephane Donze

[Valgrind-users] instruction trace

[David B. <dbr...@st...>]

Hi!
Is it possible to use valgrind to get a total number of x86 assembly
instructions issued?  Specifically, I'm trying to see how many assembly
instructions are issued for a given input into a crypto library.  I've
looked and used profiling tools such as vtune and got total number of
instructions retired, but that's not quite what I'm interested in.  I
want the total number of assembly instructions given to the processor...

If not valgrind, does anyone have any suggestions?  I can't find any
good execution tracing tools for x86 and linux....

thanks for any help!
david

Re: [Valgrind-users] checking the arguments to system calls?

[Nicholas N. <nj...@ca...>]

On Tue, 29 Apr 2003, John Reiser wrote:

> Where are the arguments to a system call checked for having defined values?
> For instance, open() can take 3 arguments, yet case __NR_open in
> coregrind/vg_syscalls.c does no checking regarding arg3.  See testcase below.
>
> If trailing arguments to mmap2() [and/or other syscalls that take many]
> are omitted, then shouldn't valgrind complain?

It's not just open() and mmap2().  All direct system call args (integers,
pointers, etc) aren't checked.  Only blocks of memory pointed to by
pointer arguments are checked.  So Valgrind won't catch any undefined
integer arguments to any system calls.

I guess Julian did it this way because these kinds of errors will
(presumably) be pretty uncommon compared to undefined blocks of memory --
you'd need an undefined stack variable or argument, and gcc -O picks up
possibly undefined stack vars -- and it would be a pain to add all the
extra checking.  Maybe it should be there, but in practice I think these
are pretty uncommon cases.  Correct me if I'm wrong...

N

[Valgrind-users] checking the arguments to system calls?

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

Where are the arguments to a system call checked for having defined values?
For instance, open() can take 3 arguments, yet case __NR_open in
coregrind/vg_syscalls.c does no checking regarding arg3.  See testcase below.

If trailing arguments to mmap2() [and/or other syscalls that take many]
are omitted, then shouldn't valgrind complain?

The checking of __NR_select and __NR_newselect is incorrect in 1.9.5:
-----
          if (arg2 != 0)
             SYSCALL_TRACK( pre_mem_read, tst, "newselect(readfds)",
                               arg2, arg1/8 /* __FD_SETSIZE/8 */ );
-----
Every instance of "arg1/8" should be "(7+arg1)/8" instead.  It is very
common for code that uses select() to "know" exactly the maximum fd in a set,
and to specify only  1+max_fd  as arg1.  So if max_fd is 3 then arg1 is 4,
and arg1/8 is zero, yet the kernel must (and does) read at least 1 byte
in this case.  In fact, examining the code for get_fd_set() in
linux/include/linux/poll.h leads to the conclusion that "4*((31 + arg1)/32)"
is the byte length that Linux actually uses on x86.  [Try putting an fd_set
high on a page, unaligned, near a page hole.]


-----bug_open.c
#include <stdlib.h>
#include <fcntl.h>
main()
{
         return open("foo", O_CREAT|O_RDWR);
/* Missing 3rd arg [permission bits] to open(), should be diagnosed
    as a read from an allocated-but-unwritten location on stack,
    followed by [an implied, and actual] use of the value by the kernel.
    As compiled by gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
    using "gcc -g" [no -O]:
         0x8048324 <main>:       push   %ebp
         0x8048325 <main+1>:     mov    %esp,%ebp
         0x8048327 <main+3>:     sub    $0x8,%esp
         0x804832a <main+6>:     and    $0xfffffff0,%esp
         0x804832d <main+9>:     mov    $0x0,%eax
         0x8048332 <main+14>:    sub    %eax,%esp
         0x8048334 <main+16>:    sub    $0x8,%esp  # 3rd arg undefined
         0x8048337 <main+19>:    push   $0x42      # 2nd arg (flags)
         0x8048339 <main+21>:    push   $0x80483f4 # 1st arg (name)
         0x804833e <main+26>:    call   0x8048264 <open>
    Similar holes can be observed with gcc < 3.2 by declaring a local
    array whose initial elements are never written.
*/
}
-----

-- 
John Reiser, jr...@Bi...

Re: [Valgrind-users] Immediate segfault with valgrind-1.9.5 on RH7.1

[Nicholas N. <nj...@ca...>]

On Mon, 28 Apr 2003, Stuart Brorson wrote:

> > This is how "make ; make install" created the script.  When I
> > uncommented "LD_DEBUG=symbols", and "export LD_DEBUG" valgrind started
> > working.  Yay!!!!
>
> Actually, the only thing this did was allow valgrind to spew a whole
> bunch of cruft before segfaulting.  Here are the last few lines before
> segfaulting:

That just tells the dynamic linker to spew out some debugging info.


> By the way, I did put in a bunch of "echo" statements into the
> valgrind script.  The place where it segfaults is when it actually
> execs the invoked program at the end of the script.  It doesn't puke
> for any of the environmental set-up statements.

Hmm, can you use GDB to find where the seg fault is happening, if it's
happening within Valgrind (presumably) and what line number?

N

Re: [Valgrind-users] Need test case for: REPE then 0xF: Unhandled REPE case

[Dominic M. <dma...@ai...>]

Here's a very short test program that produces this error for me.  I'm 
using a Pentium 3, though, not a Pentium 4.  The problem only happens if I 
use the -march=pentium3 option with gcc 3.x.

Test program:

#include <stdio.h>
#include <stdlib.h>

int main(int argc, char **argv)
{
   float f = rand() / (float)RAND_MAX;
   printf("f=%f\n", f);

   return 0;
}

Compilation line:

  gcc -march=pentium3 foo.c

> gcc -v
Thread model: posix
gcc version 3.2

> valgrind --version
valgrind-1.9.4

I hope this helps!

- Dominic

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

From: Julian Seward <js...@ac...>
To: val...@li...
Date: Sun, 27 Apr 2003 00:13:43 +0100
Subject: [Valgrind-users] Need test case for: REPE then 0xF: Unhandled 
REPE
case


Hello.  I'm trying to put together bug fixes for 1.9.6.

Several people reported this panic:

   REPE then 0xF

   valgrind: the `impossible' happened:
      Unhandled REPE case

I'd like to fix it, since it seems to afflict quite a number
of people.  However, reading my Intel P4 documentation I can't
figure out what instruction this is.

So: does anyone have a smallish test case I can use to reproduce
this with?  Or (not so good, but it would be a help) can anyone
tell me what the byte after the 0xF is?  You can find out
by changing vg_to_ucode.c:4321 from

         VG_(printf)("REPE then 0x%x\n", (UInt)abyte);

to

         VG_(printf)("REPE then 0x%x 0x%x\n", (UInt)abyte,
                                              (UInt)getUChar(eip));

I prefer a test case tho, so I can test any fix I make.

Thanks,

J

Re: [Valgrind-users] Immediate segfault with valgrind-1.9.5 on RH7.1

[<sd...@cl...>]

Rats!  I was too optimistic about fixing the problem. . . . .

> > On Mon, 28 Apr 2003, Stuart Brorson wrote:
> > 
> > > With great anticipation I downloaded and built valgrind-1.9.5 last
> > > night.  I did a vanilla "./configure ; make ; make install".  When I
> > > tried "valgrind ls -l", I got "Segmentation fault (core dumped)".
> > > Rats!  When I run valgrind alone, I also get a segfault.
> > 
> > You mean even if you just type "valgrind"?  Weird... something must going
> > wrong in Valgrind's startup shell script.

Yes, even if I just type "valgrind".

> > Can you try fiddling with $PREFIX/bin/valgrind, inserting some debug
> > "echo" statements to work out where exactly the seg fault is happening?
> > 
> > N
> 
> OK, I fixed my problem.  I examined /usr/local/bin/valgrind.  It
> turned out that at one  place in that script I had:
> 
> #LD_DEBUG=files
> #LD_DEBUG=symbols
> #export LD_DEBUG
> 
> This is how "make ; make install" created the script.  When I
> uncommented "LD_DEBUG=symbols", and "export LD_DEBUG" valgrind started
> working.  Yay!!!!

Actually, the only thing this did was allow valgrind to spew a whole
bunch of cruft before segfaulting.  Here are the last few lines before
segfaulting:

22740:  symbol=_dl_map_object_deps;  lookup in file=/lib/i686/libc.so.6
22740:  symbol=_dl_map_object_deps;  lookup in file=/lib/ld-linux.so.2
22740:  
22740:  calling init: /usr/local/lib/valgrind/valgrind.so
22740:  
22740:  symbol=__register_frame_info;  lookup in file=true
22740:  symbol=__register_frame_info;  lookup in file=/usr/local/lib/valgrind/vgskin_memcheck.so
22740:  symbol=__register_frame_info;  lookup in file=/usr/local/lib/valgrind/valgrind.so
22740:  symbol=__register_frame_info;  lookup in file=/lib/i686/libc.so.6

By the way, I did put in a bunch of "echo" statements into the
valgrind script.  The place where it segfaults is when it actually
execs the invoked program at the end of the script.  It doesn't puke
for any of the environmental set-up statements. 

Does anybody have any ideas about what is wrong?

Stuart