valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] Assertion Failed

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

In message <200...@ac...>
          Julian Seward <js...@ac...> wrote:

> But anyway, as Tom says, R H 8.1 contains NPTL, which V can't emulate
> well enough to be useful, and we don't have an ETA on fixing it either.
> Best advice is to avoid 8.1 if you want to use V.  At least for the
> moment.

I wrote my earlier message based on your comment in the documentation
that NPTL will need extra work, but I was thinking afterwards that as
valgrind replaces libpthread.so with it's own version that NPTL won't
actually get a chance to be involved will it?

Presumably there must be some other problem though, perhaps with the
use of thread local storage by the main C library or something?

Tom

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

Re: [Valgrind-users] Assertion Failed

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

> > valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 
> > 7) == 7'

> The fact that this assertion is talking about segment selectors
> suggests that thread local storage is involved, and hence this is
> probably a threading related problem.

The lowest 3 bits of the segment selector is a tag which indicates some
properties of the segment (iirc).  111b means a LDT selector, and that's
what the above assertion tests.   I think you've probably hit a 
GDT selector (011b iirc).

But anyway, as Tom says, R H 8.1 contains NPTL, which V can't emulate
well enough to be useful, and we don't have an ETA on fixing it either.
Best advice is to avoid 8.1 if you want to use V.  At least for the
moment.

J

Re: [Valgrind-users] Assertion Failed

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

In message <3E7...@br...>
        Seth Ladd <se...@br...> wrote:

> I'm attempting to run valgrind 1.9.4 on redhat 8.1 beta, using gcc
> 3.2.1.  I'm trying to run a program under it, but I get a Assertion
> failed message.  The full text of the output is included below.  I
> checked the mailing list archives, and the nano-faq, but didn't see
> this mentioned.  Does any of this ring a bell?  Is there something I
> can do?

RedHat 8.1 uses glibc 2.3 with the NPTL thread package instead of
the linuxthreads thread package and valgrind is therefore highly
unlikely to work with threaded programs under RedHat 8.1 until some
work is done to make it handle the changes to threading.

The fact that this assertion is talking about segment selectors
suggests that thread local storage is involved, and hence this is
probably a threading related problem.

Before anybody worries about the update to glibc 2.3.2 that was
released for RedHat 8.0 the other day, that version was built with
linuxthreads so there is no problem there.

Tom

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

[Valgrind-users] Assertion Failed

[Seth L. <se...@br...>]

Hello,

I'm attempting to run valgrind 1.9.4 on redhat 8.1 beta, using gcc 
3.2.1.  I'm trying to run a program under it, but I get a Assertion 
failed message.  The full text of the output is included below.  I 
checked the mailing list archives, and the nano-faq, but didn't see this 
mentioned.  Does any of this ring a bell?  Is there something I can do?

Thanks very much,
Seth

[root@disheveled .libs]# valgrind -v ./state testmode
shell-init: could not get current directory: getcwd: cannot access 
parent direct
ories: No such file or directory
sh_makepath: could not get current directory: getcwd: cannot access 
parent direc
tories: No such file or directory
==15339== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==15339== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==15339== Using valgrind-1.9.4, a program instrumentation system for 
x86-linux.
==15339== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==15339== Startup, with flags:
==15339==    --suppressions=/usr/local/lib/valgrind/default.supp
==15339==    -v
==15339== Reading suppressions file: /usr/local/lib/valgrind/default.supp
==15339== Estimated CPU clock rate is 865 MHz
==15339==

valgrind: vg_ldt.c:167 (vgPlain_do_useseg): Assertion `(seg_selector & 
7) == 7'
failed.

sched status:
Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==15339== Reading syms from /home/seth/code/G4/src/.libs/state
==15339== Reading syms from /lib/ld-2.3.1.so
==15339== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so
==15339== Reading syms from /usr/local/lib/valgrind/valgrind.so
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libcomms.so.0.0
.0
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libcurl.so.2.0.
2
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libssl.so.0.9.7
==15339== Reading syms from /lib/libdl-2.3.1.so
==15339==    object doesn't have any debug info
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libcore.so.0.0.
0
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libbrivodb.so.0
.0.0
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/librdf.so.0.0.0
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libraptor.so.0.
0.0
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libxml2.so.2.5.
3
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libz.so.1.1.4
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libcrypto.so.0.
9.7
==15339== Reading syms from 
/home/seth/code/G4/external/dist/lib/libinterface.so
.0.0.0
==15339== Reading syms from /usr/local/lib/valgrind/libpthread.so
==15339== Reading syms from /usr/lib/libstdc++.so.5.0.2
==15339== Reading syms from /lib/tls/libm-2.3.1.so
==15339== Reading syms from /lib/libgcc_s-3.2.1-20021208.so.1
==15339== Reading syms from /lib/tls/libc-2.3.1.so
==15339==    at 0x42029BA1: __new_exitfn (in /lib/tls/libc-2.3.1.so)
==15339==    by 0x42029B58: __cxa_atexit_internal (in 
/lib/tls/libc-2.3.1.so)
==15339==    by 0x404767E7: 
__static_initialization_and_destruction_0(int, int)
(/usr/src/build/177318-i386/BUILD/gcc-3.2.1-20021208/obj-i386-redhat-linux/i386-
redhat-linux/libstdc++-v3/include/iostream:63)
==15339==    by 0x40476839: 
_GLOBAL__I__ZThn8_NSt14basic_iostreamIwSt11char_trai
tsIwEED0Ev.._.._.._.._libstdc___v3_src_io_inst.ccJGVYgb 
(/usr/src/build/177318-i
386/BUILD/gcc-3.2.1-20021208/obj-i386-redhat-linux/i386-redhat-linux/libstdc++-v
3/include/bits/locale_facets.h:107)

Please report this bug to: js...@ac...

[root@disheveled .libs]# gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.1/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--disable-checking --with-system-zlib --enable-__cxa_atexit 
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.1 20021207 (Red Hat Linux 8.0 3.2.1-2)

Re: [Valgrind-users] SystemC with valgrind?

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

Julian Seward wrote:
 > Don't I know your name in connection with denotational semantics, or
 > something?

Yes, that's me.  Seems a while ago now.

 > Umm ... what's systemC ?

It's a system for simulation of hardware and other designs, built on top
of C++.  From http://www.systemc.org: "SystemC is the standard design
and verification language built in C++ that spans from concept to
implementation in hardware and software. Designers design and verify
using SystemC and standard ANSI C++. EDA vendors create tools that are
automatically interoperable."

I had written:

 >> Can anyone suggest what I should do next with the following
 >> problem?

I have now sorted this out, thank you.  It was indeed a classic
premature-deletion bug.  I think Valgrind comes out with an
"A-double-minus" grade.  It gets a basic A because it did indeed detect
the invalid use of memory which had already been freeed.  But it doesn't
quite get a straight A because:
1. It got confused about the error message (presumably because of the
multi-threading).  It ought to have told me simply that it was memory in
the free store which I'd already deallocated; instead it went on about
how it was from another thread's stack area.
2.  My setting the address invalid, by VALGRIND_MAKE_NOACCESS, seemed
not to affect my claiming it, using it and releasing it; it was only
when I used it after that that the error message told me it was because
I had invalidated it.  (Maybe that's part of the bug Julian mentions in
his message -- I had indeed included "valgrind.h", not "memcheck.h".)
3.  The documentation emphasises that the system is designed to be "as
non-intrusive as possible".  I did not therefore realises that it
nevertheless alters all the memory addresses used.  This should perhaps
be emphasised -- after all, if you're investigating memory usage errors,
addresses tend to be relevant.

Julian and Nick gave me helpful advice about gdb (some of which I was
already doing).  But the tricky part was hunting down where I  had
prematurely deleted the item.  Two ways came to mind:
1.  If the program was already printing lots of diagnostic output, run
with Valgrind's --trace-malloc=yes.  Then you can search for the delete,
and see which of your own messages surround it.
2.  If you know the type of the errant object, you can write code in its
destructor to break for the case you're looking for.
But these are both a little bit clunky.  Perhaps a Valgrind option to do
it more cleanly would be nice.  I'm not sure.

Anyway, thanks again for your help.

joe stoy

Re: [Valgrind-users] SystemC with valgrind?

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

Don't I know your name in connection with denotational semantics,
or something?

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

Umm ... what's systemC ?

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

3 comments.

1. Increase valgrind's --freelist-vol parameter to as large a number
   as you can.  The manual describes what it is and why this might
   be useful.   (do  valgrind --skin=memcheck --help, assuming you
   are using v-1.9.4).

2. If you are doing this VALGRIND_MAKE_NOACCESS with valgrind version
   1.1.0 or later, we found recently a bug in which the file to 
   include is "memcheck.h" and not "valgrind.h".  The real bad thing
   is that including "valgrind.h" still seems to work, but strange
   things happen at run time.  I've put in a fix to both the head
   and 2_0_BRANCH to cause a compilation error if you include valgrind.h
   directly, and that will be in 1.9.5.

3. As Nick rightly points out, make friends with GDB's hardware 
   watchpoints if you haven't already.  In summary, 
      watch *(int*) 0xAddressToWatch
   They've saved my ass on various occasions since I learnt of them.

J

[Valgrind-users] hardcoded /usr/bin/gdb

[Ruben G. <ru...@ug...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In valgrind 1.0.4 (dont know if this is fixed in development)
the location of gdb is hardcoded in vg_main.c as /usr/bin/gdb.

Gdb sources, on the other hand, install by default in /usr/local/bin/gdb.
Surely a patch to the ./configure to check where gdb is installed cannot 
be difficult.

Thanks!

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE+eigdkzndl97WsggRAuEiAJ4oDZHdPTA/H34ruZnO+Tfqc7tNUQCeMdoA
oG6azwlPvd+HSEeY0B1cMxo=
=bsaQ
-----END PGP SIGNATURE-----

Re: [Valgrind-users] SystemC with valgrind?

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

On Thu, 20 Mar 2003, Joe Stoy wrote:

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

I have no experience, but there shouldn't be any problems, since Valgrind
works in principle with programs written in any languages (although it can
do a bit more with C and C++ programs).

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

I don't have much to say about this, except maybe GDB watch points could
be useful?  Don't know.

N

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