valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Minor problem with latest development snapshot install on Red Hat 8.0

[Jorge R. <jo...@rm...>]

Fellow users,

When I installed the development version on redhat 8.0, the makefiles =
had trouble descending to subdirectories.  I believe the cd <subdir> =
command in the makefiles fail because the current directory is not what =
is expected.  My workaround was to change the SHELL variable in the =
makefile to /bin/bash.

Jorge Roccatagliata
Echo Inc.
4895 River Bend Dr.
Boulder CO 80301
jo...@rm...

[Valgrind-users] SystemC with valgrind?

[Joe S. <st...@sa...>]

(a)
Has anyone had experience debugging SystemC programs with valgrind? 
Were there any unexpected problems?

(b)
Can anyone suggest what I should do next with the following problem?

I have a SystemC program which maintains a number of queues, implemented 
as C++ list<packet *>.  gdb reveals that after the simulation has been 
running for a considerable time, I create and initialise a packet and 
put it on the back of one queue, but a packet with the same pointer is 
already at the front of a quite different queue and has its contents 
overwritten.  (All queues and packets are in storage around 0x8,000,000.)

This looks like a classic case of premature deletion, so I try to find 
it with valgrind.  But valgrind produces an "invalid read" error a 
little bit earlier in the simulation, and gdb shows all the packets in 
the queue about to be clobbered have now been moved to invalid addresses 
around 0x43,000,000.  (Valgrind guesses that this address is "on thread 
1's stack", but I'm not sure that's reliable.)

Running without valgrind shows, according to gdb at the relevant moment, 
no sign of this relocation.

So I reckon that if the packets have turned up in the new place, 
something (presumably with access rights) must have put them there.  So 
I try again with the offending address made invalid by a 
VALGRIND_MAKE_NOACCESS call, hoping to catch whatever it is that wrote 
them in the first place.  But the program fails in the same place as 
before (though this time the error is because I've declared the address 
invalid, not because valgrind thought it was invalid anyway).  The 
packets are all there at the new place, with their proper contents; but 
whatever it is that wrote them there snuck in under my prohibition.

Sorry to go on at length, but I'm a bit stuck.  I'd be grateful for any 
suggestions . . .

joe stoy

[Valgrind-users] Invalid free() error

[Eyal L. <ey...@ey...>]

I get the following report on program shutdown:

==10648== Time: 2003/03/20 18:05:19
==10648== Invalid free() / delete / delete[]
==10648==    at 0x4015E2CD: free (vg_clientfuncs.c:182)
==10648==    by 0x42B5DB6B: (within /lib/libc-2.2.93.so)
==10648==    by 0x42ACA021: __libc_freeres (in /lib/libc-2.2.93.so)
==10648==    by 0x4015EADD: vgPlain___libc_freeres_wrapper
(vg_clientfuncs.c:587)
==10648==    by 0x42A7C208: exit (in /lib/libc-2.2.93.so)
==10648==    by 0x429C682D: ??? (exit.c:216)
==10648==    by 0x429D467F: skmain (main.c:1098)
==10648==    by 0x8050462: main (ssasrsv.c:789)
==10648==    by 0x42A66913: __libc_start_main (in /lib/libc-2.2.93.so)
==10648==    by 0x804E3D0: (within /home/eyal/a1i/bin/ssasrsv.orig)
==10648==    Address 0x42A2A830 is not stack'd, malloc'd or free'd

The stamenet at exit.c:216 is 'exit (0)'.

What are the possible causes of this?

--
Eyal Lebedinsky (ey...@ey...) <http://samba.org/eyal/>

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Christian L. <chr...@le...>]

On Tue, Mar 18, 2003 at 10:58:20AM +0000, Nicholas Nethercote wrote:
> If you #include "profile.c" into a skin and recompile, the --profile=yes
> option turns on tick-based profiling.  That's where Julian got his 0--15%
> figure for translation from (note that's for all translation).

Ok, sorry, forgot all the junk I wrote.

make CC="gcc -falign-functions=16" install

and "running" was 1215 ticks, with 8 it's again 1315

(allway 16 byte alignment)
speed: function+loops (1349 ticks) < function (1215) < function+jump
(1207) <function+jump+label (1194) <function+jump+label+loops (1173)

compare it to the values in the other mail

At least the function alignment seem to be good on a Athlon, but I don't
know about other system, but I think that it also won't be bad.

Christian Leber

-- 
  "Omnis enim res, quae dando non deficit, dum habetur et non datur,
   nondum habetur, quomodo habenda est."       (Aurelius Augustinus)
  Translation: <http://gnuhh.org/work/fsf-europe/augustinus.html>

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Christian L. <chr...@le...>]

On Tue, Mar 18, 2003 at 10:58:20AM +0000, Nicholas Nethercote wrote:

> If you #include "profile.c" into a skin and recompile, the --profile=yes
> option turns on tick-based profiling.  That's where Julian got his 0--15%
> figure for translation from (note that's for all translation).

Sorry, a little bit late.
I runned with both, but the "resolution" isn't good enough, the
numbers are ok and reproducable.

with the patch:
core:/home/ijuz/Mail/la# time nice -n -10 /work/dev/val/bin/valgrind --profile=yes gzip -9 politech_at_politechbot_com
==25094== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==25094== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==25094== Using valgrind-1.9.4, a program instrumentation system for x86-linux.
==25094== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==25094== Estimated CPU clock rate is 1551 MHz
==25094== For more details, rerun with: -v
==25094==
==25094==
==25094== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==25094== malloc/free: in use at exit: 0 bytes in 0 blocks.
==25094== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==25094== For a detailed leak analysis,  rerun with: --leak-check=yes
==25094== For counts of detected errors, rerun with: -v

Profiling done, 1402 ticks
 0:    2 (  1 %%) ticks,           1 entries   for  unclassified
 1: 1225 (873 %%) ticks,        4759 entries   for  running
 2:    6 (  4 %%) ticks,           1 entries   for  scheduler
 3:    3 (  2 %%) ticks,       40568 entries   for  low-lev malloc/free
 4:    0 (  0 %%) ticks,           0 entries   for  client  malloc/free
 5:    0 (  0 %%) ticks,           0 entries   for  adjust-stack
 6:    0 (  0 %%) ticks,        1190 entries   for  translate-main
 7:    0 (  0 %%) ticks,        1190 entries   for  to-ucode
 8:    3 (  2 %%) ticks,        1190 entries   for  from-ucode
 9:    0 (  0 %%) ticks,        1190 entries   for  improve
10:    1 (  0 %%) ticks,        1190 entries   for  reg-alloc
11:    0 (  0 %%) ticks,        1190 entries   for  liveness-analysis
12:    0 (  0 %%) ticks,           0 entries   for  do-lru
13:    0 (  0 %%) ticks,        2382 entries   for  slow-search-transtab
14:    0 (  0 %%) ticks,           1 entries   for  init-memory
15:    0 (  0 %%) ticks,           0 entries   for  exe-context
16:    0 (  0 %%) ticks,           0 entries   for  read-syms
17:    0 (  0 %%) ticks,           0 entries   for  search-syms
18:    0 (  0 %%) ticks,           0 entries   for  add-to-transtab
19:    0 (  0 %%) ticks,         459 entries   for  core-syscall-wrapper
20:    0 (  0 %%) ticks,           0 entries   for  demangle
21:    0 (  0 %%) ticks,        3329 entries   for  core-cheap-sanity
22:    3 (  2 %%) ticks,         134 entries   for  core-expensive-sanity
23:    0 (  0 %%) ticks,           0 entries   for  pre-clo-init
24:    0 (  0 %%) ticks,           0 entries   for  post-clo-init
25:    1 (  0 %%) ticks,        1190 entries   for  instrument
26:    0 (  0 %%) ticks,         478 entries   for  skin-syscall-wrapper
27:    0 (  0 %%) ticks,        3329 entries   for  skin-cheap-sanity
28:   30 ( 21 %%) ticks,         134 entries   for  skin-expensive-sanity
29:    0 (  0 %%) ticks,           0 entries   for  fini
30:    2 (  1 %%) ticks,        1436 entries   for  check-mem-perms
31:  126 ( 89 %%) ticks,    52566183 entries   for  set-mem-perms

real    0m15.607s
user    0m13.960s
sys     0m0.090s


and without:

core:/home/ijuz/Mail/la# time nice -n -10 /work/dev/val/bin/valgrind --profile=yes gzip -9 politech_at_politechbot_com
==25629== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==25629== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==25629== Using valgrind-1.9.4, a program instrumentation system for x86-linux.
==25629== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==25629== Estimated CPU clock rate is 1545 MHz
==25629== For more details, rerun with: -v
==25629==
==25629==
==25629== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==25629== malloc/free: in use at exit: 0 bytes in 0 blocks.
==25629== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==25629== For a detailed leak analysis,  rerun with: --leak-check=yes
==25629== For counts of detected errors, rerun with: -v

Profiling done, 1528 ticks
 0:    1 (  0 %%) ticks,           1 entries   for  unclassified
 1: 1320 (863 %%) ticks,        4757 entries   for  running
 2:    9 (  5 %%) ticks,           1 entries   for  scheduler
 3:    2 (  1 %%) ticks,       40568 entries   for  low-lev malloc/free
 4:    0 (  0 %%) ticks,           0 entries   for  client  malloc/free
 5:    0 (  0 %%) ticks,           0 entries   for  adjust-stack
 6:    0 (  0 %%) ticks,        1190 entries   for  translate-main
 7:    1 (  0 %%) ticks,        1190 entries   for  to-ucode
 8:    1 (  0 %%) ticks,        1190 entries   for  from-ucode
 9:    2 (  1 %%) ticks,        1190 entries   for  improve
10:    2 (  1 %%) ticks,        1190 entries   for  reg-alloc
11:    0 (  0 %%) ticks,        1190 entries   for  liveness-analysis
12:    0 (  0 %%) ticks,           0 entries   for  do-lru
13:    0 (  0 %%) ticks,        2380 entries   for  slow-search-transtab
14:    0 (  0 %%) ticks,           1 entries   for  init-memory
15:    0 (  0 %%) ticks,           0 entries   for  exe-context
16:    0 (  0 %%) ticks,           0 entries   for  read-syms
17:    0 (  0 %%) ticks,           0 entries   for  search-syms
18:    0 (  0 %%) ticks,           0 entries   for  add-to-transtab
19:    0 (  0 %%) ticks,         459 entries   for  core-syscall-wrapper
20:    0 (  0 %%) ticks,           0 entries   for  demangle
21:    0 (  0 %%) ticks,        3329 entries   for  core-cheap-sanity
22:    7 (  4 %%) ticks,         134 entries   for  core-expensive-sanity
23:    0 (  0 %%) ticks,           0 entries   for  pre-clo-init
24:    0 (  0 %%) ticks,           0 entries   for  post-clo-init
25:    3 (  1 %%) ticks,        1190 entries   for  instrument
26:    0 (  0 %%) ticks,         478 entries   for  skin-syscall-wrapper
27:    0 (  0 %%) ticks,        3329 entries   for  skin-cheap-sanity
28:   31 ( 20 %%) ticks,         134 entries   for  skin-expensive-sanity
29:    0 (  0 %%) ticks,           0 entries   for  fini
30:    6 (  3 %%) ticks,        1436 entries   for  check-mem-perms
31:  143 ( 93 %%) ticks,    52566183 entries   for  set-mem-perms

real    0m16.796s
user    0m15.230s
sys     0m0.090s


Christian Leber 

-- 
  "Omnis enim res, quae dando non deficit, dum habetur et non datur,
   nondum habetur, quomodo habenda est."       (Aurelius Augustinus)
  Translation: <http://gnuhh.org/work/fsf-europe/augustinus.html>

[Valgrind-users] valgrind 1.94 and Red Hat Advanced Server v2.1.

[Gene G. <mus...@ya...>]

I want to confirm developers' hunch that the new stack
segment detecting code fixes RHAS problem as well.
Thanks a bundle for investigating this in the first
place!

Gene

----------------------
From 1.9.4 release notes
Changes over 1.9.3 are: 
...
Detect the stack segment at startup in a more robust
way. This fixes segfaults caused by random stack
placement in Gentoo at high security levels. It might
also help on Red Hat Advanced Server v2.1. 

..............

__________________________________________________
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!
http://platinum.yahoo.com

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

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

On Tue, 18 Mar 2003, Christian Leber wrote:

> > So I'm mystified where the 7% speedup number comes from.
>
> Yes, absolutly, it's very obscure.
>
> Some little changes decresed the performance again, damn, I fooled
> myself.
>
> It could be some alignment effect.
> So perhaps this stupid 7% are also only on athlon-xp's.
>
> But I don't know how to analyse what function takes how long, than it
> should be easy to find the function were this difference is.

If you #include "profile.c" into a skin and recompile, the --profile=yes
option turns on tick-based profiling.  That's where Julian got his 0--15%
figure for translation from (note that's for all translation).

N

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Christian L. <chr...@le...>]

On Tue, Mar 18, 2003 at 08:45:08AM +0000, Julian Seward wrote:

> The computed goto thing is useful for speeding up bytecode interpreters
> -- I've used it for that before now -- but this isn't such a case.  It's
> the switch in the x86 parser which switches on the opcodes being
> examined.  It is used only once per instruction which V translates and
> so the cost difference (a few host insns) must be completely swamped by
> the rest of the translation costs (000s of host insns per translated
> insn, typically).  And translation costs are usually small (0-15%)
> compared to the cost of running the translation.  

> So I'm mystified where
> the 7% speedup number comes from.

Yes, absolutly, it's very obscure.

Some little changes decresed the performance again, damn, I fooled
myself.

It could be some alignment effect.
So perhaps this stupid 7% are also only on athlon-xp's.

But I don't know how to analyse what function takes how long, than it
should be easy to find the function were this difference is.


Christian Leber

-- 
  "Omnis enim res, quae dando non deficit, dum habetur et non datur,
   nondum habetur, quomodo habenda est."       (Aurelius Augustinus)
  Translation: <http://gnuhh.org/work/fsf-europe/augustinus.html>

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

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

[2nd try at getting this to v-users list]

On Monday 17 March 2003 7:37 pm, Nicholas Nethercote wrote:
> On Mon, 17 Mar 2003, Jason Evans wrote:
> > > But the numbers are not good, actually a performance decrease against
> > > switch().
> >
> > I've recently been doing some experimentation with computed gotos in an
> > unrelated program, and I've also observed a slowdown in most cases.  This
> > indicates to me that gcc typically does a fine job of optimizing switch
> > statements, and there isn't a whole lot to be gained by second guessing
> > it in such cases.

The computed goto thing is useful for speeding up bytecode interpreters
-- I've used it for that before now -- but this isn't such a case.  It's
the switch in the x86 parser which switches on the opcodes being
examined.  It is used only once per instruction which V translates and
so the cost difference (a few host insns) must be completely swamped by
the rest of the translation costs (000s of host insns per translated
insn, typically).  And translation costs are usually small (0-15%)
compared to the cost of running the translation.  So I'm mystified where
the 7% speedup number comes from.

J

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

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

On Mon, 17 Mar 2003, Jason Evans wrote:

> > But the numbers are not good, actually a performance decrease against
> > switch().
>
> I've recently been doing some experimentation with computed gotos in an
> unrelated program, and I've also observed a slowdown in most cases.  This
> indicates to me that gcc typically does a fine job of optimizing switch
> statements, and there isn't a whole lot to be gained by second guessing it
> in such cases.

I think Christian got good results with the first version, but not with
the second version that computes each label address as a difference from a
base label address.  So it looks like it (the first version) is
worthwhile.

I've had mixed successes with computed gotos in the past as well...
branch prediction is very important;  I once tried the computed goto trick
which saved me quite a few instructions, but made the branches more or
less unpredictable, and the end result was little difference.

N

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Jason E. <ja...@ca...>]

On Mon, Mar 17, 2003 at 03:33:13PM +0100, Christian Leber wrote:
> On Mon, Mar 17, 2003 at 12:37:52PM +0000, Nicholas Nethercote wrote:
> 
> > Valgrind is packaged as a shared library.  Perhaps this might improve
> > things further?
> 
> Ok, I changed it (patch included).
> 
> But the numbers are not good, actually a performance decrease against
> switch().

I've recently been doing some experimentation with computed gotos in an
unrelated program, and I've also observed a slowdown in most cases.  This
indicates to me that gcc typically does a fine job of optimizing switch
statements, and there isn't a whole lot to be gained by second guessing it
in such cases.

Jason

Re: [Valgrind-users] rpm dependency problem (Red Hat 7.3) failed dependencies: libc.so.6(GLIBC_PRIVATE)

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

In message <XFM...@lu...>
        Greg Hosler <ho...@lu...> wrote:

> I recently tried building an rpm for valgrind 1.0.4
> (http://developer.kde.org/~sewardj/) (the spec file is in the tar.bz2 file)
> 
> the rpm spec file looks pretty innocent.
> 
> at the end of the rpm build, during dependency checking I see:
> 
> 
>    Requires: ld-linux.so.2 libc.so.6 /bin/sh /usr/bin/perl libc.so.6(GLIBC_2.0)
>    libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.2) libc.so.6(GLIBC_2.1.3)
>    libc.so.6(GLIBC_PRIVATE)
>    Wrote: /home/hosler/WIP/rpmbuild/RPMS/valgrind-1.0.4-1.i386.rpm
> 
> When I try to install the rpm (Red Hat 7.3, all eratta applied), I get the
> following error message:
> 
>         rpm -ivh valgrind-1.0.4-1.i386.rpm 
>         error: failed dependencies:
>                 libc.so.6(GLIBC_PRIVATE)   is needed by valgrind-1.0.4-1
> 
> Now the interesting thing is:
> 
>         # strings /lib/libc.so.6 | grep GLIBC_PRIVATE
>         GLIBC_PRIVATE
> 
> so the pre-requisite symbol is infact in the library, and
> /usr/lib/rpm/find-requires found it, get when rpm goes to install, it can't
> verify that the dependency is satisfied.

The symbols in question - there are actually two - are indeed present
in glibc, but recent releases have given them a version of GLIBC_PRIVATE
to indicate that they are for internal use only. The symbols in question
are:

  __pthread_clock_gettime
  __pthread_clock_settime
 
Both of these are referenced in valgrind's special libpthread.so and
hence are picked up by rpmbuild as dependencies. The problem is that
rpm knows that those are private symbols and doesn't consider that
the glibc package satisfies them, hence the error.

You can force the install with --no-deps and it will all run just
fine, or you can hack the package building to avoid adding that
dependency, which is what I do. I have this script in my RPM sources
directory as valgrind-find-requires:

#!/bin/sh

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

and then I add this macro to my valgrind.spec file:

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

Tom

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

[Valgrind-users] rpm dependency problem (Red Hat 7.3) failed dependencies: libc.so.6(GLIBC_PRIVATE)

[Greg H. <ho...@lu...>]

Hi,

I recently tried building an rpm for valgrind 1.0.4
(http://developer.kde.org/~sewardj/) (the spec file is in the tar.bz2 file)

the rpm spec file looks pretty innocent.

at the end of the rpm build, during dependency checking I see:


   Requires: ld-linux.so.2 libc.so.6 /bin/sh /usr/bin/perl libc.so.6(GLIBC_2.0)
   libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.1.2) libc.so.6(GLIBC_2.1.3)
   libc.so.6(GLIBC_PRIVATE)
   Wrote: /home/hosler/WIP/rpmbuild/RPMS/valgrind-1.0.4-1.i386.rpm

When I try to install the rpm (Red Hat 7.3, all eratta applied), I get the
following error message:

        rpm -ivh valgrind-1.0.4-1.i386.rpm 
        error: failed dependencies:
                libc.so.6(GLIBC_PRIVATE)   is needed by valgrind-1.0.4-1

Now the interesting thing is:

        # strings /lib/libc.so.6 | grep GLIBC_PRIVATE
        GLIBC_PRIVATE

so the pre-requisite symbol is infact in the library, and
/usr/lib/rpm/find-requires found it, get when rpm goes to install, it can't
verify that the dependency is satisfied.

is this an rpm bug (kind of feels like it :(
is there a way around this particular situation ?

thank you, and best regards,

-Greg Hosler

+---------------------------------------------------------------------+
   You can release software that's good, software that's inexpensive, or
   software that's available on time.  You can usually release software
   that has 2 of these 3 attributes -- but not all 3.
| Greg Hosler                                   ho...@lu...    |
+---------------------------------------------------------------------+

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Christian L. <chr...@le...>]

On Mon, Mar 17, 2003 at 12:37:52PM +0000, Nicholas Nethercote wrote:

> Valgrind is packaged as a shared library.  Perhaps this might improve
> things further?

Ok, I changed it (patch included).

But the numbers are not good, actually a performance decrease against
switch().

gzip:
13.78user 0.03system 0:14.21elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
13.71user 0.06system 0:14.16elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k

bzip2:
48.49user 0.10system 0:49.79elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
48.66user 0.04system 0:50.06elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k

latex:
real    0m5.056s
user    0m4.880s
sys     0m0.090s

Regards,
Christian Leber

-- 
  "Omnis enim res, quae dando non deficit, dum habetur et non datur,
   nondum habetur, quomodo habenda est."       (Aurelius Augustinus)
  Translation: <http://gnuhh.org/work/fsf-europe/augustinus.html>

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Christian L. <chr...@le...>]

On Mon, Mar 17, 2003 at 12:37:52PM +0000, Nicholas Nethercote wrote:

> 1. Can you try it with a few other programs?  It would be nice to see if
> the 7% speedup is consistent across programs.  Some programs I've used
> for performance timing in the past:
> 
>    gzip
>    bzip2

48.36user 0.05system 0:49.79elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
48.47user 0.07system 0:51.22elapsed 94%CPU (0avgtext+0avgdata
0maxresident)k

patched:
47.93user 0.09system 0:49.17elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
47.91user 0.09system 0:49.22elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k

>    latex

real    0m5.088s
user    0m4.790s
sys     0m0.130s

patched:
real    0m4.741s
user    0m4.490s
sys     0m0.140s

>    konqueror (startup then quit immediately)

It eats up all CPU till it -9 kill it when I quit it.
(I still have KDE 2.2)

> 2. The bottom of the webpage you mention says:
> 
>    "An alternate way to write the above example is
> 
>    static const int array[] = { &&foo - &&foo, &&bar - &&foo,
>                                 &&hack - &&foo };
>    goto *(&&foo + array[i]);
> 
>    This is more friendly to code living in shared libraries, as it reduces
>    the number of dynamic relocations that are needed, and by consequence,
>    allows the data to be read-only."
> 
> Valgrind is packaged as a shared library.  Perhaps this might improve
> things further?

Yes, but initially I did not get it working, was a little stupid error.
I'll try it, but this takes some time.

cachegrind shows me with a little test programm, that it's slower with
the later thing. But it's not a shared library and I don't know how
often it has to be done.


Regards,
Christian Leber

-- 
  "Omnis enim res, quae dando non deficit, dum habetur et non datur,
   nondum habetur, quomodo habenda est."       (Aurelius Augustinus)
  Translation: <http://gnuhh.org/work/fsf-europe/augustinus.html>

Re: [Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

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

On Mon, 17 Mar 2003, Christian Leber wrote:

> I saw this realy big switch(opt){case 0x00....} statement and thought
> "this must be slow".
>
> So I tried the "Labels as Values" feature of the gcc.
> (http://www.dis.com/gnu/gcc/gcc_79.html#SEC79)
> Yes it is a gcc feature, but because is specially for x86/Linux I can't
> see a problem.

[snip]

> 13.54 -> 12.55
> that is a speedup of about 7% in this case
>
> If you (Julian or Nick) are perhaps interested in it, I would clean it up
> further and remove this one switch() { } statement.

Interesting.  Two comments:

1. Can you try it with a few other programs?  It would be nice to see if
the 7% speedup is consistent across programs.  Some programs I've used
for performance timing in the past:

   gzip
   bzip2
   latex
   konqueror (startup then quit immediately)

Batch programs are obviously more suitable for this.


2. The bottom of the webpage you mention says:

   "An alternate way to write the above example is

   static const int array[] = { &&foo - &&foo, &&bar - &&foo,
                                &&hack - &&foo };
   goto *(&&foo + array[i]);

   This is more friendly to code living in shared libraries, as it reduces
   the number of dynamic relocations that are needed, and by consequence,
   allows the data to be read-only."

Valgrind is packaged as a shared library.  Perhaps this might improve
things further?


If you could try these two experiments, and tell us the results, that
would be very helpful.

Thanks.

N

[Valgrind-users] Preliminary little speedup patch (seen 7% speedup)

[Christian L. <chr...@le...>]

Hello,

first let me say:

valgrind is absolutly great, thank you for it!
It saved me allready often.

Because I was not able to add MMX support (seems not to be exactly
easy).
I saw this realy big switch(opt){case 0x00....} statement and thought
"this must be slow".

So I tried the "Labels as Values" feature of the gcc.
(http://www.dis.com/gnu/gcc/gcc_79.html#SEC79)
Yes it is a gcc feature, but because is specially for x86/Linux I can't
see a problem.

"benchmark":
core:/home/ijuz/Mail/la# ls -l
total 4508
-rw-------    1 ijuz     ijuz      4602189 Mar 17 11:56
politech_at_politechbot_com

core:/home/ijuz/Mail/la# nice -n -10 time /work/dev/val/bin/valgrind
gzip -9 politech_at_politechbot_com

normali-cvs:
13.57user 0.09system 0:14.07elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k
13.51user 0.08system 0:14.01elapsed 96%CPU (0avgtext+0avgdata
0maxresident)k

patched-cvs:
12.54user 0.06system 0:13.07elapsed 96%CPU (0avgtext+0avgdata
0maxresident)k
12.56user 0.06system 0:12.97elapsed 97%CPU (0avgtext+0avgdata
0maxresident)k

this means (average):

13.54 -> 12.55
that is a speedup of about 7% in this case

If you (Julian or Nick) are perhaps interested in it, I would clean it up
further and remove this one switch() { } statement.

I appended the patch, I hope nobody objects because of this few kb.
(It is against the cvs from now)

Regards,
Christian Leber

-- 
  "Omnis enim res, quae dando non deficit, dum habetur et non datur,
   nondum habetur, quomodo habenda est."       (Aurelius Augustinus)
  Translation: <http://gnuhh.org/work/fsf-europe/augustinus.html>

[Valgrind-users] Here's a nano-FAQ

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

Something to get started with ... here's a nano-FAQ I assembled for
the 1.0.X branch but didn't get round to putting in the 2.0.X branch
yet.  Maybe the FAQ will grow as a result of this list.

J

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


A mini-FAQ for valgrind, versions 1.0.4 and 1.1.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Last revised 13 Oct 2002
~~~~~~~~~~~~~~~~~~~~~~~~


Q1. Programs run OK on valgrind, but at exit produce a bunch
    of errors a bit like this

    ==20755== Invalid read of size 4
    ==20755==    at 0x40281C8A: _nl_unload_locale (loadlocale.c:238)
    ==20755==    by 0x4028179D: free_mem (findlocale.c:257)
    ==20755==    by 0x402E0962: __libc_freeres (set-freeres.c:34)
    ==20755==    by 0x40048DCC: vgPlain___libc_freeres_wrapper
                                              (vg_clientfuncs.c:585)
    ==20755==    Address 0x40CC304C is 8 bytes inside a block of size 380 
free'd
    ==20755==    at 0x400484C9: free (vg_clientfuncs.c:180)
    ==20755==    by 0x40281CBA: _nl_unload_locale (loadlocale.c:246)
    ==20755==    by 0x40281218: free_mem (setlocale.c:461)
    ==20755==    by 0x402E0962: __libc_freeres (set-freeres.c:34)

    and then die with a segmentation fault.

A1. When the program exits, valgrind runs the procedure
    __libc_freeres() in glibc.  This is a hook for memory debuggers,
    so they can ask glibc to free up any memory it has used.  Doing
    that is needed to ensure that valgrind doesn't incorrectly
    report space leaks in glibc.

    Problem is that running __libc_freeres() in older glibc versions
    causes this crash.

    WORKAROUND FOR 1.0.X versions of valgrind: The simple fix is to
    find in valgrind's sources, the one and only call to
    __libc_freeres() and comment it out, then rebuild the system.  In
    the 1.0.3 version, this call is on line 584 of vg_clientfuncs.c.
    This may mean you get false reports of space leaks in glibc, but
    it at least avoids the crash.

    WORKAROUND FOR 1.1.X and later versions of valgrind: use the
    --run-libc-freeres=no flag.



Q2. My program dies complaining that syscall 197 is unimplemented.

A2. 197, which is fstat64, is supported by valgrind.  The problem is
    that the /usr/include/asm/unistd.h on the machine on which your
    valgrind was built, doesn't match your kernel -- or, to be more
    specific, glibc is asking your kernel to do a syscall which is
    not listed in /usr/include/asm/unistd.h.

    The fix is simple.  Somewhere near the top of vg_syscall_mem.c,
    add the following line:

       #define __NR_fstat64            197

    Rebuild and try again.  The above line should appear before any
    uses of the __NR_fstat64 symbol in that file.  If you look at the
    place where __NR_fstat64 is used in vg_syscall_mem.c, it will be
    obvious why this fix works.  NOTE for valgrind versions 1.1.0
    and later, the relevant file is actually coregrind/vg_syscalls.c.


Q3. My (buggy) program dies like this:
      valgrind: vg_malloc2.c:442 (bszW_to_pszW):
                Assertion `pszW >= 0' failed.
    And/or my (buggy) program runs OK on valgrind, but dies like
    this on cachegrind.

A3. If valgrind shows any invalid reads, invalid writes and invalid
    frees in your program, the above may happen.  Reason is that your
    program may trash valgrind's low-level memory manager, which then
    dies with the above assertion, or something like this.  The cure
    is to fix your program so that it doesn't do any illegal memory
    accesses.  The above failure will hopefully go away after that.


Q4. I'm running Red Hat Advanced Server.  Valgrind always segfaults at
    startup.

A4. [Note: fixed properly in 1.9.4; the following stuff is now redundant]

    Known issue with RHAS 2.1.  The following kludge works, but
    is too gruesome to put in the sources permanently.  Try it.
    Last verified as working on RHAS 2.1 at 20021008.

    Find the following comment in vg_main.c -- in 1.0.4 this is at
    line 636:

       /* we locate: NEW_AUX_ENT(1, AT_PAGESZ, ELF_EXEC_PAGESIZE) in
          the elf interpreter table */

    Immediately _before_ this comment add the following:

       /* HACK for R H Advanced server.  Ignore all the above and
          start the search 18 pages below the "obvious" start point.
          God knows why.  Seems like we can't go into the highest 18
          pages of the stack.  This is not good! -- the 18 pages is
          determined just by looking for the highest proddable
          address.  It would be nice to see some kernel or libc or
          something code to justify this.  */

       /* 0xBFFEE000 is 0xC0000000 - 18 pages */
       sp = 0xBFFEE000;

       /* end of HACK for R H Advanced server. */

    Obviously the assignment to sp is the only important line.


(this is the end of the FAQ.)

[Valgrind-users] Test message

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

Well, like wot the Subject line says ...

J