valgrind-users — General discussion list for Valgrind users

[Valgrind-users] Recommended gcc version

[Leonard m. <spa...@ya...>]

Pulled CVS today and I'm getting 10s of thousands of Mismatched free
errors that aren't mismatched, a known issue reported earlier in the
archives.

What version of gcc are the valgrind developers running with?  I'll
just rebuild my app tree with that and be done with it.

Thanks,

Randall

P.S.  BTW, thanks for the SSE patches and improved thread support!
I'm thrilled I can run some apps through valgrind now that I couldn't
before.



__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Valgrind-users] Valgrind + blas and lapack + Mismatched free() / delete

[Sami R. <sam...@un...>]

Hi,

I just downloaded valgrind from cvs and the problem persists :

valgrind-cvs/bin/valgrind -v --alignment=8 --leak-check=yes
--num-callers=8 linux/debug/icia fit.conf 27.conf

...

disInstr: unhandled instruction bytes: 0xF 0x57 0xE4 0xF
Illegal instruction


Additionally I get much more errors with the cvs version of valgrind
than with the version 1.9.6: Now, I get many Mismatched free() / delete
/ delete []

I tried to look in the doc what this error means, but couldn't find it.
So I guess, it's because I used 'delete [] ptr'  instead of 'delete ptr'
or vide-versa. But I couldn't find this in my code. So is this a
valgrind bug or my bug ?

Thanks,

Sami.

On Thu, 2003-05-29 at 11:05, Nicholas Nethercote wrote:
> On Thu, 29 May 2003, Sami Romdhani wrote:
> 
> > I know that there is no support in valgrind for mmx, sse and sse2
> > instructions.
> 
> There is now:  grab the latest version from CVS
> (sourceforge.net/cvs/?group_id=46268) and follow instructions in README to
> install.
> 
> I think MMX support is complete, or close to complete, and SSE/SSE2
> support is at least partly done.  Hopefully it will get things working for
> you.
> 
> N
> 
-- 
http://informatik.unibas.ch/personen/romdhani_sami/

Re: [Valgrind-users] Valgrind/Cachegrind stack overflow problem with Wine app

[Jeremy F. <je...@go...>]

On Mon, 2003-06-09 at 01:04, Prashant Verma wrote:
> I was trying to run valgrind with wine. As an example
> app I used Acrobat Reader.exe The following command
> gives a stack overflow problem:

Does the same thing happen with the Linux native version of acroread?  I
would guess that the core code is the same for the two versions, and it
might indicate whether acroread really needs a huge stack, or its some
artifact of the wine+acroread combination.

	J

[Valgrind-users] OH ALSO

[Joshua Moore-O. <jo...@ch...>]

If you are using gnetoo make sure you compile with --emptytree so that all 
depencies are recompiled as well...  I ran into this problem with glibc and 
command line programs, recompiling glibc was not enough, I needed to 
recompile glibc AND it's dependancies.

Hope to have helped you out.

Josh.

On June 9, 2003 11:01 am, Dan Kegel wrote:
> Which version of gcc?  gcc-3.3 fixes a whole bunch of pentium 4 bugs.
> - Dan
>
> Joshua Moore-Oliva wrote:
> > Just a warning, but march=pentium 4 is broken in gcc.
> >
> > I've had everything from sound problems to floating point conversion
> > problems due to it...  If you have anything compiled with march=pentium4
> > I'd definately recommend downgrading to at least march=pentium3 since
> > pentium4 has a floating point conversion bug that's really nasty.
> >
> > On June 9, 2003 10:30 am, Olivier Chapuis wrote:
> >>On Sun, Jun 08, 2003 at 09:56:49AM -0400, Joshua Moore-Oliva wrote:
> >>>What system are you running?
> >>>
> >>>The only time I got that error was when I was running gentoo and ran the
> >>>march=pentium[34] gcc flags..
> >>>
> >>>Currently I have compiled my system with
> >>>
> >>>march=i686 =O2 pipe -fomit-frame-pointer
> >>>
> >>>and it works well.
> >>>
> >>>Josh.
> >>
> >>Yes I compiled X with these options (as I've a pentium4):
> >>
> >>-O2 -march=pentium4 -fno-strength-reduce -pipe
> >>
> >>will try with march=i686.
> >>
> >>Thanks, Olivier
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> >>thread debugger on the planet. Designed with thread debugging features
> >>you've never dreamed of, try TotalView 6 free at www.etnus.com.
> >>_______________________________________________
> >>Valgrind-users mailing list
> >>Val...@li...
> >>https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > thread debugger on the planet. Designed with thread debugging features
> > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Problems with XFree-4.3

[Dan K. <da...@ke...>]

Yeah... worth a shot, though.  Most of the gcc 3.3 problems I've
seen so far are for other architectures (like sh4).
- Dan

Joshua Moore-Oliva wrote:
> Actually I think it is fixed in gcc 3.3 however I'm nto running it yet cause 
> it's not marked stable yet :)
> 
> Just thought I'd give youa  heads up.
> 
> On June 9, 2003 11:01 am, Dan Kegel wrote:
> 
>>Which version of gcc?  gcc-3.3 fixes a whole bunch of pentium 4 bugs.
>>- Dan
>>
>>Joshua Moore-Oliva wrote:
>>
>>>Just a warning, but march=pentium 4 is broken in gcc.
>>>
>>>I've had everything from sound problems to floating point conversion
>>>problems due to it...  If you have anything compiled with march=pentium4
>>>I'd definately recommend downgrading to at least march=pentium3 since
>>>pentium4 has a floating point conversion bug that's really nasty.
>>>
>>>On June 9, 2003 10:30 am, Olivier Chapuis wrote:
>>>
>>>>On Sun, Jun 08, 2003 at 09:56:49AM -0400, Joshua Moore-Oliva wrote:
>>>>
>>>>>What system are you running?
>>>>>
>>>>>The only time I got that error was when I was running gentoo and ran the
>>>>>march=pentium[34] gcc flags..
>>>>>
>>>>>Currently I have compiled my system with
>>>>>
>>>>>march=i686 =O2 pipe -fomit-frame-pointer
>>>>>
>>>>>and it works well.
>>>>>
>>>>>Josh.
>>>>
>>>>Yes I compiled X with these options (as I've a pentium4):
>>>>
>>>>-O2 -march=pentium4 -fno-strength-reduce -pipe
>>>>
>>>>will try with march=i686.
>>>>
>>>>Thanks, Olivier



-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: [Valgrind-users] Problems with XFree-4.3

[Joshua Moore-O. <jo...@ch...>]

Actually I think it is fixed in gcc 3.3 however I'm nto running it yet cause 
it's not marked stable yet :)

Just thought I'd give youa  heads up.

On June 9, 2003 11:01 am, Dan Kegel wrote:
> Which version of gcc?  gcc-3.3 fixes a whole bunch of pentium 4 bugs.
> - Dan
>
> Joshua Moore-Oliva wrote:
> > Just a warning, but march=pentium 4 is broken in gcc.
> >
> > I've had everything from sound problems to floating point conversion
> > problems due to it...  If you have anything compiled with march=pentium4
> > I'd definately recommend downgrading to at least march=pentium3 since
> > pentium4 has a floating point conversion bug that's really nasty.
> >
> > On June 9, 2003 10:30 am, Olivier Chapuis wrote:
> >>On Sun, Jun 08, 2003 at 09:56:49AM -0400, Joshua Moore-Oliva wrote:
> >>>What system are you running?
> >>>
> >>>The only time I got that error was when I was running gentoo and ran the
> >>>march=pentium[34] gcc flags..
> >>>
> >>>Currently I have compiled my system with
> >>>
> >>>march=i686 =O2 pipe -fomit-frame-pointer
> >>>
> >>>and it works well.
> >>>
> >>>Josh.
> >>
> >>Yes I compiled X with these options (as I've a pentium4):
> >>
> >>-O2 -march=pentium4 -fno-strength-reduce -pipe
> >>
> >>will try with march=i686.
> >>
> >>Thanks, Olivier
> >>
> >>
> >>-------------------------------------------------------
> >>This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> >>thread debugger on the planet. Designed with thread debugging features
> >>you've never dreamed of, try TotalView 6 free at www.etnus.com.
> >>_______________________________________________
> >>Valgrind-users mailing list
> >>Val...@li...
> >>https://lists.sourceforge.net/lists/listinfo/valgrind-users
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> > thread debugger on the planet. Designed with thread debugging features
> > you've never dreamed of, try TotalView 6 free at www.etnus.com.
> > _______________________________________________
> > Valgrind-users mailing list
> > Val...@li...
> > https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Problems with XFree-4.3

[Dan K. <da...@ke...>]

Which version of gcc?  gcc-3.3 fixes a whole bunch of pentium 4 bugs.
- Dan

Joshua Moore-Oliva wrote:
> Just a warning, but march=pentium 4 is broken in gcc.
> 
> I've had everything from sound problems to floating point conversion problems 
> due to it...  If you have anything compiled with march=pentium4 I'd 
> definately recommend downgrading to at least march=pentium3 since pentium4 
> has a floating point conversion bug that's really nasty.
> 
> On June 9, 2003 10:30 am, Olivier Chapuis wrote:
> 
>>On Sun, Jun 08, 2003 at 09:56:49AM -0400, Joshua Moore-Oliva wrote:
>>
>>>What system are you running?
>>>
>>>The only time I got that error was when I was running gentoo and ran the
>>>march=pentium[34] gcc flags..
>>>
>>>Currently I have compiled my system with
>>>
>>>march=i686 =O2 pipe -fomit-frame-pointer
>>>
>>>and it works well.
>>>
>>>Josh.
>>
>>Yes I compiled X with these options (as I've a pentium4):
>>
>>-O2 -march=pentium4 -fno-strength-reduce -pipe
>>
>>will try with march=i686.
>>
>>Thanks, Olivier
>>
>>
>>-------------------------------------------------------
>>This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
>>thread debugger on the planet. Designed with thread debugging features
>>you've never dreamed of, try TotalView 6 free at www.etnus.com.
>>_______________________________________________
>>Valgrind-users mailing list
>>Val...@li...
>>https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 
> 


-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Re: [Valgrind-users] Problems with XFree-4.3

[Joshua Moore-O. <jo...@ch...>]

Just a warning, but march=pentium 4 is broken in gcc.

I've had everything from sound problems to floating point conversion problems 
due to it...  If you have anything compiled with march=pentium4 I'd 
definately recommend downgrading to at least march=pentium3 since pentium4 
has a floating point conversion bug that's really nasty.

On June 9, 2003 10:30 am, Olivier Chapuis wrote:
> On Sun, Jun 08, 2003 at 09:56:49AM -0400, Joshua Moore-Oliva wrote:
> > What system are you running?
> >
> > The only time I got that error was when I was running gentoo and ran the
> > march=pentium[34] gcc flags..
> >
> > Currently I have compiled my system with
> >
> > march=i686 =O2 pipe -fomit-frame-pointer
> >
> > and it works well.
> >
> > Josh.
>
> Yes I compiled X with these options (as I've a pentium4):
>
> -O2 -march=pentium4 -fno-strength-reduce -pipe
>
> will try with march=i686.
>
> Thanks, Olivier
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] Problems with XFree-4.3

[Olivier C. <oli...@fr...>]

On Sun, Jun 08, 2003 at 09:56:49AM -0400, Joshua Moore-Oliva wrote:
> 
> What system are you running?
> 
> The only time I got that error was when I was running gentoo and ran the 
> march=pentium[34] gcc flags..
> 
> Currently I have compiled my system with
> 
> march=i686 =O2 pipe -fomit-frame-pointer
> 
> and it works well.
> 
> Josh.
>

Yes I compiled X with these options (as I've a pentium4):

-O2 -march=pentium4 -fno-strength-reduce -pipe

will try with march=i686.

Thanks, Olivier

Re: [Valgrind-users] Valgrind/Cachegrind stack overflow problem with Wine app

[Prashant V. <pra...@ya...>]

I just reran valgrind 1.9.6-wine with the following
command line (without cachegrind):
valgrind --trace-children=yes wine ./Acrobat.exe
And this time it stopped with :
disInstr: unhandled opcode 0x94 then 0x8B

valgrind: the `impossible' happened:
   unhandled x86 opcode
Basic block ctr is approximately 91650000

This is followed by some lines of sched status.

For the stack size previously running cachegrind, I've
tried 32<<20 (thats 1<<25).I'll try with 1<<27, but I
wonder if this could point to a bug.

-Prashant

--- Nicholas Nethercote <nj...@ca...> wrote:
> On Mon, 9 Jun 2003, Prashant Verma wrote:
> 
> > Hi,
> > I was trying to run valgrind with wine. As an
> example
> > app I used Acrobat Reader.exe The following
> command
> > gives a stack overflow problem:
> > valgrind --trace-children=yes --skin=cachegrind
> wine
> > ./Acrobat.exe
> > The error I get is:
> > ==21778== Error: STACK OVERFLOW: thread 2: stack
> used 33628844, available 33554416
> > ==21778== Terminating Valgrind.  If thread(s)
> really need more stack, increase
> > ==21778== VG_PTHREAD_STACK_SIZE in vg_include.h
> and recompile.
> >
> > I have increased the stack size as the above error
> > message shows, from the original (1<<20).
> 
> Looks like you've increased it to (1<<25), but that
> still wasn't big
> enough... have you tried (1<<26) or (1<<27)?
> 
> Either way, that seems like a very big stack.  Do
> you have the same
> problems with other apps?  Do you have the same
> problems with other skins,
> or only Cachegrind?
> 
> N
> 


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Valgrind-users] Valgrind/Cachegrind stack overflow problem with Wine app

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

On Mon, 9 Jun 2003, Prashant Verma wrote:

> Hi,
> I was trying to run valgrind with wine. As an example
> app I used Acrobat Reader.exe The following command
> gives a stack overflow problem:
> valgrind --trace-children=yes --skin=cachegrind wine
> ./Acrobat.exe
> The error I get is:
> ==21778== Error: STACK OVERFLOW: thread 2: stack used 33628844, available 33554416
> ==21778== Terminating Valgrind.  If thread(s) really need more stack, increase
> ==21778== VG_PTHREAD_STACK_SIZE in vg_include.h and recompile.
>
> I have increased the stack size as the above error
> message shows, from the original (1<<20).

Looks like you've increased it to (1<<25), but that still wasn't big
enough... have you tried (1<<26) or (1<<27)?

Either way, that seems like a very big stack.  Do you have the same
problems with other apps?  Do you have the same problems with other skins,
or only Cachegrind?

N

[Valgrind-users] Valgrind/Cachegrind stack overflow problem with Wine app

[Prashant V. <pra...@ya...>]

Hi,
I was trying to run valgrind with wine. As an example
app I used Acrobat Reader.exe The following command
gives a stack overflow problem:
valgrind --trace-children=yes --skin=cachegrind wine
./Acrobat.exe
The error I get is:
==21778== Error: STACK OVERFLOW: thread 2: stack used
33628844, available 33554416
==21778== Terminating Valgrind.  If thread(s) really
need more stack, increase
==21778== VG_PTHREAD_STACK_SIZE in vg_include.h and
recompile.

I have increased the stack size as the above error
message shows, from the original (1<<20).

If I run wine without valgrind, there is no problem,
i.e. the following:
wine ./Acrobat.exe runs fine.

Any suggestions on what could be going wrong and how
to fix it?

-Prashant


__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com

Re: [Valgrind-users] Problems with XFree-4.3

[Joshua Moore-O. <jo...@ch...>]

What system are you running?

The only time I got that error was when I was running gentoo and ran the 
march=pentium[34] gcc flags..

Currently I have compiled my system with

march=i686 =O2 pipe -fomit-frame-pointer

and it works well.

Josh.

On June 6, 2003 12:17 pm, Olivier Chapuis wrote:
> Hello,
>
> When I used valgrind (cvs head) with a programs which use the XFree-4.3.x
> libraries I get the following:
>
> [olivier@snoopy valgrind]$ valgrind -v xcalc
> ==21680== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
> ==21680== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
> ==21680== Using valgrind-1.9.4, a program supervision framework for
> x86-linux. ==21680== Copyright (C) 2000-2003, and GNU GPL'd, by Julian
> Seward. ==21680== Startup, with flags:
> ==21680==    --suppressions=/usr/local/lib/valgrind/default.supp
> ==21680==    -v
> ==21680== Reading suppressions file: /usr/local/lib/valgrind/default.supp
> ==21680== Estimated CPU clock rate is 2016 MHz
> ==21680==
> ==21680==
> ==21680== Valgrind detected that your program requires
> ==21680== the following unimplemented functionality:
> ==21680==    x86 segment override (SEG=CS) prefix
> ==21680== This may be because the functionality is hard to implement,
> ==21680== or because no reasonable program would behave this way,
> ==21680== or because nobody has yet needed it.  In any case, let me know
> ==21680== (js...@ac...) and/or try to work around the problem, if you
> can. ==21680==
> ==21680== Valgrind has to exit now.  Sorry.  Bye!
> ==21680==
>
> sched status:
>
> Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
> ==21680== Reading syms from /home/olivier/local/opt/X/bin/xcalc
> ==21680== Reading syms from /lib/ld-2.2.5.so
> ==21680== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so
> ==21680== Reading syms from /usr/local/lib/valgrind/valgrind.so
> ==21680== Reading syms from /home/olivier/local/opt/X/lib/libXaw.so.7.0
> ==21680== Reading syms from /home/olivier/local/opt/X/lib/libXmu.so.6.2
> ==21680== Reading syms from /home/olivier/local/opt/X/lib/libXt.so.6.0
> ==21680== Reading syms from /home/olivier/local/opt/X/lib/libSM.so.6.0
> ==21680== Reading syms from /home/olivier/local/opt/X/lib/libICE.so.6.3
> ==21680== Reading syms from /home/olivier/local/opt/X/lib/libXpm.so.4.11
> ==21680== Reading syms from /home/olivier/local/opt/X/lib/libXext.so.6.4
> ==21680== Reading syms from /home/olivier/local/opt/X/lib/libX11.so.6.2
> ==21680== Reading syms from /lib/i686/libm-2.2.5.so
> ==21680==    object doesn't have a symbol table
> ==21680==    object doesn't have any debug info
> ==21680== Reading syms from /lib/i686/libc-2.2.5.so
> ==21680==    object doesn't have a symbol table
> ==21680==    object doesn't have any debug info
> ==21680== Reading syms from /lib/libdl-2.2.5.so
> ==21680==    object doesn't have a symbol table
> ==21680==    object doesn't have any debug info
> ==21680==    at 0x4032BE6C: permalloc (in
> /home/olivier/local/opt/X/lib/libX11.so.6.2) ==21680==    by 0x4032BFD3:
> ExpandQuarkTable (in /home/olivier/local/opt/X/lib/libX11.so.6.2) ==21680==
>    by 0x4032C214: _XrmInternalStringToQuark (in
> /home/olivier/local/opt/X/lib/libX11.so.6.2) ==21680==    by 0x4032C482:
> XrmPermStringToQuark (in /home/olivier/local/opt/X/lib/libX11.so.6.2)
>
>
> If I use the XFree-4.2.1 libs I've not this problem.
>
> Any help welcome ...
>
> Thanks a lot for valgrind, a great software!
>
> Regards, Olivier
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] unsubscribe

[Roland V. P. <rol...@wa...>]

unsubscribe
----- Original Message -----
From: <val...@li...>
To: <val...@li...>
Sent: Friday, June 06, 2003 12:41 PM
Subject: Valgrind-users digest, Vol 1 #84 - 9 msgs


> Send Valgrind-users mailing list submissions to
> val...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> or, via email, send a message with subject or body 'help' to
> val...@li...
>
> You can reach the person managing the list at
> val...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Valgrind-users digest..."
>
>
> Today's Topics:
>
>    1. Re: __builtin_new and its buddies (Josef Weidendorfer)
>    2. Re: __builtin_new and its buddies (Alex Ivershen)
>    3. Re: __builtin_new and its buddies (Josef Weidendorfer)
>    4. Re: __builtin_new and its buddies (Alex Ivershen)
>    5. Pre-instrumented vs JIT instrumentation (Mike Bresnahan)
>    6. Re: Pre-instrumented vs JIT instrumentation (Alex Ivershen)
>    7. Re: Pre-instrumented vs JIT instrumentation (Mike Bresnahan)
>    8. Re: Pre-instrumented vs JIT instrumentation (Nicholas Nethercote)
>    9. Problem with libpthread.. (Joshua Moore-Oliva)
>
> --__--__--
>
> Message: 1
> From: Josef Weidendorfer <Jos...@gm...>
> To: Alex Ivershen <ale...@in...>
> Subject: Re: [Valgrind-users] __builtin_new and its buddies
> Date: Thu, 5 Jun 2003 09:56:29 +0200
> Cc: val...@li...
>
> On Thursday 05 June 2003 00:52, Alex Ivershen wrote:
> > <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> > <html>
> > Gentlemen,
> > <p>I am still having issues with __builtin_new not being intercepted by
> > Valgrind.&nbsp; Jeremy Fitzhardinge gave me some suggestions, but it did
> > not solve the issue. Here is the problem: when I am compling certain
> > classes, the compiler generates references to __builtin_new (vec_new,
> > delete, vec_delete) in the object file.&nbsp; When this object file is
> > linked into executable, the compiler resolves the __builtin* references
> > from libgcc.a, where they are defined as "W" symbols.
> > <p>As a result,&nbsp; Valgrind does NOT intercept those __builtin*
> > functions, and only catches malloc() and free() calls when these classes
> > are used. As you can imagine, a swarm of musmatched free/delete/delete[]
is
>
> Your object files seem to be fine.
> The problem is, that the static link process shouldn't resolve
__builtin_new,
> i.e. the libgcc.a you mention seems to be wrong, if it really defines
> __builtin_new statically. Perhaps this file shouldn't be linked in or is
from
> a wrong compiler version? Or you do some partial static linking. What's
your
> link command line?
>
> I just checked with my own installation of GCC 2.95.3 (Suse8.1).
> If I compile your Classes2.95.3.o with a dummy main(), it links fine, and
in
> the resulting executable, there *is* the symbol __builtin_new, so there
will
> be no problem with valgrind ?!?
> Usually, "__builtin_new" is defined in "libstdc++-libc6.2-2.so.3" and will
be
> linked in by the runtime library.
>
> Josef
>
>
> --__--__--
>
> Message: 2
> Date: Thu, 05 Jun 2003 09:34:02 -0500
> From: Alex Ivershen <ale...@in...>
> To: Josef Weidendorfer <Jos...@gm...>
> CC: val...@li...
> Subject: Re: [Valgrind-users] __builtin_new and its buddies
>
> Sm9zZWYsDQoNCldpdGggdGhlIHRlc3QgY2xhc3NlcywgSSBhbSBsaW5raW5nIHNpbXBseSBh
> cyAiZysrIC1vIFRFU1QgbWFpbi5vDQpDbGFzc2VzMi45NS4zLm8iLiBUaGUgbGliZ2NjLmEg
> bGlicmFyeSBzZWVtcyB0byBiZSBjb3JyZWN0IHRvIG1lIC0gdGhhdCB3YXMNCmJ1aWx0IGFs
> b25nIHdpdGggdGhlIGNvbXBpbGVyIGFuZCBuZXZlciBnYXZlIG1lIGFueSBncmllZi4gIFlv
> dSBhcmUgc2FpeWluZyB0aGF0DQoiIFVzdWFsbHksIF9fYnVpbHRpbl9uZXcgaXMgZGVmaW5l
> ZCBpbiAibGlic3RkYysrLWxpYmM2LjItMi5zby4zIiBhbmQgd2lsbCBiZQ0KbGlua2VkIGlu
> IGJ5IHRoZSBydW50aW1lIGxpYnJhcnkuIiAtIGhvd2V2ZXIsIGxpYnN0ZGMrKyBpbiBteSBp
> bnN0YWxsYXRpb24gaXMNClNUQVRJQywgdGhlcmUgaXMgYSBzcGVjaWZpYyByZXF1aXJlbWVu
> dCBub3QgdG8gdXNlIGFueSBzaGFyZWQgY29tcGlsZXINCmxpYnJhcmllcy4gU28sIGluIHN0
> YXRpYyBsaWJzdGRjKysgX19idWlsdGluX25ldyBhcmUgIlUiIHN5bWJvbHMuIFRoZSBvbmx5
> IHBsYWNlDQp0aGUgcHJvZ3JhbSBjYW4gcHVsbCB0aGUgZGVmaW5pdGlvbnMgZnJvbSBpcyBs
> aWJnY2MuYS4gIEkgdHJpZWQNCiItbm9zdGRsaWJyYXJpZXMiIHN3aWNoIHRvIHRoZSBjb21w
> aWxlciB0byBwcmV2ZW50IGhpbSBmcm9tIHB1bGxpbmcgaXQgYnkNCmRlZmF1bHQsIGJ1dCB0
> aGVuLCBvZiBjb3Vyc2UsIHRoZSBhcHAgd29uJ3QgbGluaywgY2l0aW5nICB1bnJlc29sdmVk
> IHN5bWJvbHMuDQoNCk5vdywgd2hlbiB5b3UgZG8gIm5tIiBvbiB5b3VyIHRlc3QgYXBwbGlj
> YXRpb24sIHdoYXQgaXMgdGhlIHN5bWJvbCB0eXBlIGZvcg0KIl9fYnVpbHRpbl9uZXciPyAg
> QW5kIEkgYW0gZ3Vlc3NpbmcgdGhhdCAibGRkIiBzaG93cyBkZXBlbmRlbmN5IG9uDQoibGli
> c3RkYysrLWxpYmM2LjItMi5zby4zIiAtIHRoZSBhcHBsaWNhdGlvbiBleHBlY3RzIHRvIHJl
> c29sdmUgaXQgYXQgcnVuLXRpbWUNCmZyb20gbGlic3RkYysrIGFuZCBWYWxncmluZCBoYXMg
> YSBjaGFuY2UgdG8gaW50ZXJjZXB0IGV2ZXJ5dGluZywgcmlnaHQ/ICBTbywgdGhlDQpib3R0
> b20gbGluZSBzZWVtcyB0byBiZSB0aGF0IGlmIEkgdXNlIHN0YXRpYyBsaWJzdGRjKyssIEkg
> YW0gc2NyZXdlZD8gVWdoIC4uLg0KDQpBbGV4DQoNCg0KSm9zZWYgV2VpZGVuZG9yZmVyIHdy
> b3RlOg0KDQo+IE9uIFRodXJzZGF5IDA1IEp1bmUgMjAwMyAwMDo1MiwgQWxleCBJdmVyc2hl
> biB3cm90ZToNCj4gPiA8IWRvY3R5cGUgaHRtbCBwdWJsaWMgIi0vL3czYy8vZHRkIGh0bWwg
> NC4wIHRyYW5zaXRpb25hbC8vZW4iPg0KPiA+IDxodG1sPg0KPiA+IEdlbnRsZW1lbiwNCj4g
> PiA8cD5JIGFtIHN0aWxsIGhhdmluZyBpc3N1ZXMgd2l0aCBfX2J1aWx0aW5fbmV3IG5vdCBi
> ZWluZyBpbnRlcmNlcHRlZCBieQ0KPiA+IFZhbGdyaW5kLiZuYnNwOyBKZXJlbXkgRml0emhh
> cmRpbmdlIGdhdmUgbWUgc29tZSBzdWdnZXN0aW9ucywgYnV0IGl0IGRpZA0KPiA+IG5vdCBz
> b2x2ZSB0aGUgaXNzdWUuIEhlcmUgaXMgdGhlIHByb2JsZW06IHdoZW4gSSBhbSBjb21wbGlu
> ZyBjZXJ0YWluDQo+ID4gY2xhc3NlcywgdGhlIGNvbXBpbGVyIGdlbmVyYXRlcyByZWZlcmVu
> Y2VzIHRvIF9fYnVpbHRpbl9uZXcgKHZlY19uZXcsDQo+ID4gZGVsZXRlLCB2ZWNfZGVsZXRl
> KSBpbiB0aGUgb2JqZWN0IGZpbGUuJm5ic3A7IFdoZW4gdGhpcyBvYmplY3QgZmlsZSBpcw0K
> PiA+IGxpbmtlZCBpbnRvIGV4ZWN1dGFibGUsIHRoZSBjb21waWxlciByZXNvbHZlcyB0aGUg
> X19idWlsdGluKiByZWZlcmVuY2VzDQo+ID4gZnJvbSBsaWJnY2MuYSwgd2hlcmUgdGhleSBh
> cmUgZGVmaW5lZCBhcyAiVyIgc3ltYm9scy4NCj4gPiA8cD5BcyBhIHJlc3VsdCwmbmJzcDsg
> VmFsZ3JpbmQgZG9lcyBOT1QgaW50ZXJjZXB0IHRob3NlIF9fYnVpbHRpbioNCj4gPiBmdW5j
> dGlvbnMsIGFuZCBvbmx5IGNhdGNoZXMgbWFsbG9jKCkgYW5kIGZyZWUoKSBjYWxscyB3aGVu
> IHRoZXNlIGNsYXNzZXMNCj4gPiBhcmUgdXNlZC4gQXMgeW91IGNhbiBpbWFnaW5lLCBhIHN3
> YXJtIG9mIG11c21hdGNoZWQgZnJlZS9kZWxldGUvZGVsZXRlW10gaXMNCj4NCj4gWW91ciBv
> YmplY3QgZmlsZXMgc2VlbSB0byBiZSBmaW5lLg0KPiBUaGUgcHJvYmxlbSBpcywgdGhhdCB0
> aGUgc3RhdGljIGxpbmsgcHJvY2VzcyBzaG91bGRuJ3QgcmVzb2x2ZSBfX2J1aWx0aW5fbmV3
> LA0KPiBpLmUuIHRoZSBsaWJnY2MuYSB5b3UgbWVudGlvbiBzZWVtcyB0byBiZSB3cm9uZywg
> aWYgaXQgcmVhbGx5IGRlZmluZXMNCj4gX19idWlsdGluX25ldyBzdGF0aWNhbGx5LiBQZXJo
> YXBzIHRoaXMgZmlsZSBzaG91bGRuJ3QgYmUgbGlua2VkIGluIG9yIGlzIGZyb20NCj4gYSB3
> cm9uZyBjb21waWxlciB2ZXJzaW9uPyBPciB5b3UgZG8gc29tZSBwYXJ0aWFsIHN0YXRpYyBs
> aW5raW5nLiBXaGF0J3MgeW91cg0KPiBsaW5rIGNvbW1hbmQgbGluZT8NCj4NCj4gSSBqdXN0
> IGNoZWNrZWQgd2l0aCBteSBvd24gaW5zdGFsbGF0aW9uIG9mIEdDQyAyLjk1LjMgKFN1c2U4
> LjEpLg0KPiBJZiBJIGNvbXBpbGUgeW91ciBDbGFzc2VzMi45NS4zLm8gd2l0aCBhIGR1bW15
> IG1haW4oKSwgaXQgbGlua3MgZmluZSwgYW5kIGluDQo+IHRoZSByZXN1bHRpbmcgZXhlY3V0
> YWJsZSwgdGhlcmUgKmlzKiB0aGUgc3ltYm9sIF9fYnVpbHRpbl9uZXcsIHNvIHRoZXJlIHdp
> bGwNCj4gYmUgbm8gcHJvYmxlbSB3aXRoIHZhbGdyaW5kID8hPw0KPiBVc3VhbGx5LCAiX19i
> dWlsdGluX25ldyIgaXMgZGVmaW5lZCBpbiAibGlic3RkYysrLWxpYmM2LjItMi5zby4zIiBh
> bmQgd2lsbCBiZQ0KPiBsaW5rZWQgaW4gYnkgdGhlIHJ1bnRpbWUgbGlicmFyeS4NCj4NCj4g
> Sm9zZWYNCg0KLS0NCkFsZXggRy4gSXZlcnNoZW4gICAgICAgICAgICAgICAgICAgICAgICAg
> ICAgSW5ldCBUZWNobm9sb2dpZXMsIEluYy4NCk5ldHdvcmsgUHJvZHVjdHMgRGVwdC4gICAg
> ICAgICAgICAgICAgICAgICAgMTUwMCBOLiBHcmVlbnZpbGxlIEF2ZS4NCkluZXQgVGVjaG5v
> bG9naWVzIEluYy4gICAgICAgICAgICAgICAgICAgICAgUmljaGFyZHNvbiwgVFggNzUwODEN
> ClBob25lOiArMS00NjktMzMwLTQyOTUgICAgICAgICAgICAgICAgICAgICAgVVNBDQoNCiJD
> b21wdXRlciBnYW1lcyBkb24ndCBhZmZlY3Qga2lkczsgSSBtZWFuIGlmIFBhYy1NYW4gYWZm
> ZWN0ZWQgdXMgYXMga2lkcywgd2UnZA0KYWxsIGJlIHJ1bm5pbmcgYXJvdW5kIGluIGRhcmtl
> bmVkIHJvb21zLCBtdW5jaGluZyBtYWdpYyBwaWxscyBhbmQgbGlzdGVuaW5nIHRvDQpyZXBl
> dGl0aXZlIGVsZWN0cm9uaWMgbXVzaWMuIiAtLSBLcmlzdGlhbiBXaWxzb24sIE5pbnRlbmRv
> LCBJbmMNCg0KDQo=
>
>
> --__--__--
>
> Message: 3
> From: Josef Weidendorfer <Jos...@gm...>
> To: Alex Ivershen <ale...@in...>
> Subject: Re: [Valgrind-users] __builtin_new and its buddies
> Date: Thu, 5 Jun 2003 17:19:50 +0200
> Cc: val...@li...
>
> On Thursday 05 June 2003 16:34, Alex Ivershen wrote:
> > Josef,
> >
> > With the test classes, I am linking simply as "g++ -o TEST main.o
> > Classes2.95.3.o". The libgcc.a library seems to be correct to me - that
was
> > built along with the compiler and never gave me any grief.  You are
saiying
> > that " Usually, __builtin_new is defined in "libstdc++-libc6.2-2.so.3"
and
> > will be linked in by the runtime library." - however, libstdc++ in my
> > installation is STATIC, there is a specific requirement not to use any
>
> Ok. So this is the culprit, and makes sense:
> If the (static) linker detects a symbol in different libraries, it prefers
> symbols from shared libraries and lets the runtime linker do the resolving
> (this at least seems to be true because __builtin_new is defined as weak
(W)
> in libgcc.a).
>
> Then your requirements (only static libs from the compiler) effectively
> prohibit the use of Valgrind for you.
>
> > shared compiler libraries. So, in static libstdc++ __builtin_new are "U"
> > symbols. The only place the program can pull the definitions from is
> > libgcc.a.  I tried
> > "-nostdlibraries" swich to the compiler to prevent him from pulling it
by
> > default, but then, of course, the app won't link, citing  unresolved
> > symbols.
> >
> > Now, when you do "nm" on your test application, what is the symbol type
for
> > "__builtin_new"?  And I am guessing that "ldd" shows dependency on
> > "libstdc++-libc6.2-2.so.3" - the application expects to resolve it at
> > run-time from libstdc++ and Valgrind has a chance to intercept
everyting,
>
> Yes.
>
> > right?  So, the bottom line seems to be that if I use static libstdc++,
I
> > am screwed? Ugh ...
>
> Sure. You can't use Valgrind with static linked binaries, and that seems
to
> hold true with even partial static binaries (as you don't have a
> "libstdc++-libc6.2-2.so.3").
>
> But perhaps you can link in a shared library of your own with
__builtin_new,
> calling malloc. At least this would allow to run the application with
> Valgrind, or even better: Put valgrind.so into your link line!
>
> Josef
>
> >
> > Alex
> >
> > Josef Weidendorfer wrote:
> > > On Thursday 05 June 2003 00:52, Alex Ivershen wrote:
> > > > <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> > > > <html>
> > > > Gentlemen,
> > > > <p>I am still having issues with __builtin_new not being intercepted
by
> > > > Valgrind.&nbsp; Jeremy Fitzhardinge gave me some suggestions, but it
> > > > did not solve the issue. Here is the problem: when I am compling
> > > > certain classes, the compiler generates references to __builtin_new
> > > > (vec_new, delete, vec_delete) in the object file.&nbsp; When this
> > > > object file is linked into executable, the compiler resolves the
> > > > __builtin* references from libgcc.a, where they are defined as "W"
> > > > symbols.
> > > > <p>As a result,&nbsp; Valgrind does NOT intercept those __builtin*
> > > > functions, and only catches malloc() and free() calls when these
> > > > classes are used. As you can imagine, a swarm of musmatched
> > > > free/delete/delete[] is
> > >
> > > Your object files seem to be fine.
> > > The problem is, that the static link process shouldn't resolve
> > > __builtin_new, i.e. the libgcc.a you mention seems to be wrong, if it
> > > really defines __builtin_new statically. Perhaps this file shouldn't
be
> > > linked in or is from a wrong compiler version? Or you do some partial
> > > static linking. What's your link command line?
> > >
> > > I just checked with my own installation of GCC 2.95.3 (Suse8.1).
> > > If I compile your Classes2.95.3.o with a dummy main(), it links fine,
and
> > > in the resulting executable, there *is* the symbol __builtin_new, so
> > > there will be no problem with valgrind ?!?
> > > Usually, "__builtin_new" is defined in "libstdc++-libc6.2-2.so.3" and
> > > will be linked in by the runtime library.
> > >
> > > Josef
> >
> > --
> > Alex G. Ivershen                            Inet Technologies, Inc.
> > Network Products Dept.                      1500 N. Greenville Ave.
> > Inet Technologies Inc.                      Richardson, TX 75081
> > Phone: +1-469-330-4295                      USA
> >
> > "Computer games don't affect kids; I mean if Pac-Man affected us as
kids,
> > we'd all be running around in darkened rooms, munching magic pills and
> > listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
> > Inc
>
>
>
> --__--__--
>
> Message: 4
> Date: Thu, 05 Jun 2003 13:12:10 -0500
> From: Alex Ivershen <ale...@in...>
> To: Josef Weidendorfer <Jos...@gm...>
> CC: val...@li...
> Subject: Re: [Valgrind-users] __builtin_new and its buddies
>
> Sm9zZWYsDQoNCkkgdGhhbmsgeW91IHNvIG11Y2ggZm9yIHlvdXIgYXNzaXRhbmNlISBDbGVh
> cmVkIHVwIHRoaW5ncyBmb3IgbWUgcXVpdGUgYSBiaXQuDQpXaGF0IEkgcmVzb3J0ZWQgdG8g
> ZG9pbmcgaXMgYnVpbGRpbmcgYSBzaGFyZWQgbGlic3RkYysrIGxpYnJhcnkgYW5kIGZvcmNl
> DQppbi1ob3VzZSBidWlsZHMgdG8gdXNlIHRoZSBzaGFyZWQgbGlicmFyeSBhbmQgZXh0ZXJu
> YWwgcmVsZWFzZXMgdG8gbGluaw0Kc3RhdGljYWxseS4gIFZhbGdyaW5kIGlzIHdvcmtpbmcg
> cGVyZmVjdGx5IHdpdGggc2hhcmVkIGxpYnN0ZGMrKy4gTWlnaHQgYmUgd29ydGgNCmFkZGlu
> ZyB0byBWYWxncmluZCBGQVE/DQoNClRoYW5rcyBhZ2FpbiEgUmVnYXJkcywNCkFsZXgNCg0K
> DQpKb3NlZiBXZWlkZW5kb3JmZXIgd3JvdGU6DQoNCj4gT24gVGh1cnNkYXkgMDUgSnVuZSAy
> MDAzIDAwOjUyLCBBbGV4IEl2ZXJzaGVuIHdyb3RlOg0KPiA+IDwhZG9jdHlwZSBodG1sIHB1
> YmxpYyAiLS8vdzNjLy9kdGQgaHRtbCA0LjAgdHJhbnNpdGlvbmFsLy9lbiI+DQo+ID4gPGh0
> bWw+DQo+ID4gR2VudGxlbWVuLA0KPiA+IDxwPkkgYW0gc3RpbGwgaGF2aW5nIGlzc3VlcyB3
> aXRoIF9fYnVpbHRpbl9uZXcgbm90IGJlaW5nIGludGVyY2VwdGVkIGJ5DQo+ID4gVmFsZ3Jp
> bmQuJm5ic3A7IEplcmVteSBGaXR6aGFyZGluZ2UgZ2F2ZSBtZSBzb21lIHN1Z2dlc3Rpb25z
> LCBidXQgaXQgZGlkDQo+ID4gbm90IHNvbHZlIHRoZSBpc3N1ZS4gSGVyZSBpcyB0aGUgcHJv
> YmxlbTogd2hlbiBJIGFtIGNvbXBsaW5nIGNlcnRhaW4NCj4gPiBjbGFzc2VzLCB0aGUgY29t
> cGlsZXIgZ2VuZXJhdGVzIHJlZmVyZW5jZXMgdG8gX19idWlsdGluX25ldyAodmVjX25ldywN
> Cj4gPiBkZWxldGUsIHZlY19kZWxldGUpIGluIHRoZSBvYmplY3QgZmlsZS4mbmJzcDsgV2hl
> biB0aGlzIG9iamVjdCBmaWxlIGlzDQo+ID4gbGlua2VkIGludG8gZXhlY3V0YWJsZSwgdGhl
> IGNvbXBpbGVyIHJlc29sdmVzIHRoZSBfX2J1aWx0aW4qIHJlZmVyZW5jZXMNCj4gPiBmcm9t
> IGxpYmdjYy5hLCB3aGVyZSB0aGV5IGFyZSBkZWZpbmVkIGFzICJXIiBzeW1ib2xzLg0KPiA+
> IDxwPkFzIGEgcmVzdWx0LCZuYnNwOyBWYWxncmluZCBkb2VzIE5PVCBpbnRlcmNlcHQgdGhv
> c2UgX19idWlsdGluKg0KPiA+IGZ1bmN0aW9ucywgYW5kIG9ubHkgY2F0Y2hlcyBtYWxsb2Mo
> KSBhbmQgZnJlZSgpIGNhbGxzIHdoZW4gdGhlc2UgY2xhc3Nlcw0KPiA+IGFyZSB1c2VkLiBB
> cyB5b3UgY2FuIGltYWdpbmUsIGEgc3dhcm0gb2YgbXVzbWF0Y2hlZCBmcmVlL2RlbGV0ZS9k
> ZWxldGVbXSBpcw0KPg0KPiBZb3VyIG9iamVjdCBmaWxlcyBzZWVtIHRvIGJlIGZpbmUuDQo+
> IFRoZSBwcm9ibGVtIGlzLCB0aGF0IHRoZSBzdGF0aWMgbGluayBwcm9jZXNzIHNob3VsZG4n
> dCByZXNvbHZlIF9fYnVpbHRpbl9uZXcsDQo+IGkuZS4gdGhlIGxpYmdjYy5hIHlvdSBtZW50
> aW9uIHNlZW1zIHRvIGJlIHdyb25nLCBpZiBpdCByZWFsbHkgZGVmaW5lcw0KPiBfX2J1aWx0
> aW5fbmV3IHN0YXRpY2FsbHkuIFBlcmhhcHMgdGhpcyBmaWxlIHNob3VsZG4ndCBiZSBsaW5r
> ZWQgaW4gb3IgaXMgZnJvbQ0KPiBhIHdyb25nIGNvbXBpbGVyIHZlcnNpb24/IE9yIHlvdSBk
> byBzb21lIHBhcnRpYWwgc3RhdGljIGxpbmtpbmcuIFdoYXQncyB5b3VyDQo+IGxpbmsgY29t
> bWFuZCBsaW5lPw0KPg0KPiBJIGp1c3QgY2hlY2tlZCB3aXRoIG15IG93biBpbnN0YWxsYXRp
> b24gb2YgR0NDIDIuOTUuMyAoU3VzZTguMSkuDQo+IElmIEkgY29tcGlsZSB5b3VyIENsYXNz
> ZXMyLjk1LjMubyB3aXRoIGEgZHVtbXkgbWFpbigpLCBpdCBsaW5rcyBmaW5lLCBhbmQgaW4N
> Cj4gdGhlIHJlc3VsdGluZyBleGVjdXRhYmxlLCB0aGVyZSAqaXMqIHRoZSBzeW1ib2wgX19i
> dWlsdGluX25ldywgc28gdGhlcmUgd2lsbA0KPiBiZSBubyBwcm9ibGVtIHdpdGggdmFsZ3Jp
> bmQgPyE/DQo+IFVzdWFsbHksICJfX2J1aWx0aW5fbmV3IiBpcyBkZWZpbmVkIGluICJsaWJz
> dGRjKystbGliYzYuMi0yLnNvLjMiIGFuZCB3aWxsIGJlDQo+IGxpbmtlZCBpbiBieSB0aGUg
> cnVudGltZSBsaWJyYXJ5Lg0KPg0KPiBKb3NlZg0KDQotLQ0KQWxleCBHLiBJdmVyc2hlbiAg
> ICAgICAgICAgICAgICAgICAgICAgICAgICBJbmV0IFRlY2hub2xvZ2llcywgSW5jLg0KTmV0
> d29yayBQcm9kdWN0cyBEZXB0LiAgICAgICAgICAgICAgICAgICAgICAxNTAwIE4uIEdyZWVu
> dmlsbGUgQXZlLg0KSW5ldCBUZWNobm9sb2dpZXMgSW5jLiAgICAgICAgICAgICAgICAgICAg
> ICBSaWNoYXJkc29uLCBUWCA3NTA4MQ0KUGhvbmU6ICsxLTQ2OS0zMzAtNDI5NSAgICAgICAg
> ICAgICAgICAgICAgICBVU0ENCg==
>
>
> --__--__--
>
> Message: 5
> Reply-To: "Mike Bresnahan" <mbr...@vi...>
> From: "Mike Bresnahan" <mbr...@vi...>
> To: <Val...@li...>
> Date: Thu, 5 Jun 2003 17:22:38 -0500
> Subject: [Valgrind-users] Pre-instrumented vs JIT instrumentation
>
> I am new to valgrind, but I have used Rational Quantify.  Excuse if this
is
> a FAQ, but I could not find anything in the FAQ nor in the mailing list
> archive.
>
> I am curious why valgrind chooses to instrument on-the-fly every time the
> application is executed rather than instrumenting the application ahead of
> time and reexecuting the same instrumented executable each time, a la
> Quantify.  To my perhaps naive mind it seems like instrumenting on-the-fly
> is less efficient.  Can someone lend some insight?
>
> Mike
>
>
>
> --__--__--
>
> Message: 6
> Date: Thu, 05 Jun 2003 17:41:19 -0500
> From: Alex Ivershen <ale...@in...>
> To: Mike Bresnahan <mbr...@vi...>
> CC: Val...@li...
> Subject: Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation
>
> <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> <html>
> Valgrind, unlike Rational suite tools, does not "instrument"
anything.&nbsp;
> That's the beauty of it - you don't need to recompile (or in case ot
Quantify
> re-link) the application.&nbsp; The difference is that Rational tools
embed
> extra code inside your object files and libraries - for memory or
performance
> profiling. As a result, executable size, shared libraries sizes are huge
> and executiion suffers greatly (esp. with purify). Valgrind, on the other
> hand, runs your application on a synthetic CPU, all the machine
instructions
> of your app are executed by Valgrind on this CPU and memory/performance
> profiling is done there, not in your app code.&nbsp; As far as Quantify
> comparison, cachegrind sking gives you much more information - e.g.
Quantify
> does not report cache usage profile.
> <p>Last but not least - Valgrind is free, has MUCH&nbsp;better developer
> support, and is updated more frequently.
> <br>Downside - only runs on x86 Linux, exactly because of synthetic CPU
> - porting it to other platforms is too much work, so developers chose the
> most popular platform.
> <p>Regards,
> <br>Alex
> <p>Mike Bresnahan wrote:
> <blockquote TYPE=CITE>I am new to valgrind, but I have used Rational
Quantify.&nbsp;
> Excuse if this is
> <br>a FAQ, but I could not find anything in the FAQ nor in the mailing
> list
> <br>archive.
> <p>I am curious why valgrind chooses to instrument on-the-fly every time
> the
> <br>application is executed rather than instrumenting the application
ahead
> of
> <br>time and reexecuting the same instrumented executable each time, a
> la
> <br>Quantify.&nbsp; To my perhaps naive mind it seems like instrumenting
> on-the-fly
> <br>is less efficient.&nbsp; Can someone lend some insight?
> <p>Mike
> <p>-------------------------------------------------------
> <br>This SF.net email is sponsored by:&nbsp; Etnus, makers of TotalView,
> The best
> <br>thread debugger on the planet. Designed with thread debugging features
> <br>you've never dreamed of, try TotalView 6 free at www.etnus.com.
> <br>_______________________________________________
> <br>Valgrind-users mailing list
> <br>Val...@li...
> <br><a
href="https://lists.sourceforge.net/lists/listinfo/valgrind-users">https://l
ists.sourceforge.net/lists/listinfo/valgrind-users</a></blockquote>
>
> <pre>--&nbsp;
> Alex G.
Ivershen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp; Inet Technologies, Inc.
> Network Products
Dept.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1500 N. Greenville
Ave.
> Inet Technologies
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Richardson, TX 75081
> Phone:
+1-469-330-4295&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USA
>
> "Computer games don't affect kids; I mean if Pac-Man affected us as kids,
we'd&nbsp;
> all be running around in darkened rooms, munching magic pills and
listening to
> repetitive electronic music." -- Kristian Wilson, Nintendo, Inc</pre>
> &nbsp;</html>
>
>
>
> --__--__--
>
> Message: 7
> Reply-To: "Mike Bresnahan" <mbr...@vi...>
> From: "Mike Bresnahan" <mbr...@vi...>
> To: <Val...@li...>
> Subject: Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation
> Date: Thu, 5 Jun 2003 18:00:15 -0500
>
> Perhaps I misunderstand how valgrind works.  I have the understanding
that,
> using the synthetic CPU, valgrind instruments the application on the fly
and
> stores the instrumented code blocks in a cache.  The author describes this
> process here
http://developer.kde.org/~sewardj/docs-1.9.5/mc_techdocs.html.
>
> Do I misunderstand?
>
> Note that Quanitfy for Windows does not require a relink.  You just point
it
> at an executable and off it goes.  First it instruments the executable and
> dependent DLLs and then it executes it.  The UNIX version requires a
> relink - or at least it did when I last used it in the mid-1990's on HPUX.
>
> Mike Bresnahan
> ----- Original Message -----
> From: "Alex Ivershen" <ale...@in...>
> To: "Mike Bresnahan" <mbr...@vi...>
> Cc: <Val...@li...>
> Sent: Thursday, June 05, 2003 5:41 PM
> Subject: Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation
>
>
> > Valgrind, unlike Rational suite tools, does not "instrument" anything.
> That's the beauty of it - you don't need to recompile (or in case ot
> Quantify re-link) the application.  The difference is that Rational tools
> embed extra code inside your object files and libraries - for memory or
> performance profiling. As a result, executable size, shared libraries
sizes
> are huge and executiion suffers greatly (esp. with purify). Valgrind, on
the
> other hand, runs your application on a synthetic CPU, all the machine
> instructions of your app are executed by Valgrind on this CPU and
> memory/performance profiling is done there, not in your app code.  As far
as
> Quantify comparison, cachegrind sking gives you much more information -
e.g.
> Quantify does not report cache usage profile.
> > Last but not least - Valgrind is free, has MUCH better developer
support,
> and is updated more frequently.
> > Downside - only runs on x86 Linux, exactly because of synthetic CPU -
> porting it to other platforms is too much work, so developers chose the
most
> popular platform.
> >
> > Regards,
> > Alex
>
>
>
> --__--__--
>
> Message: 8
> Date: Fri, 6 Jun 2003 10:08:11 +0100 (BST)
> From: Nicholas Nethercote <nj...@ca...>
> To: Mike Bresnahan <mbr...@vi...>
> cc: Val...@li...
> Subject: Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation
>
> On Thu, 5 Jun 2003, Mike Bresnahan wrote:
>
> > Perhaps I misunderstand how valgrind works.  I have the understanding
that,
> > using the synthetic CPU, valgrind instruments the application on the fly
and
> > stores the instrumented code blocks in a cache.  The author describes
this
> > process here
http://developer.kde.org/~sewardj/docs-1.9.5/mc_techdocs.html.
> >
> > Do I misunderstand?
>
> You are right, Valgrind instruments the app dynamically.
>
> I think when Alex said Valgrind doesn't "instrument" anything, he meant
> that you don't have to do anything explicit, in a separate step.
>
> > Note that Quanitfy for Windows does not require a relink.  You just
point it
> > at an executable and off it goes.  First it instruments the executable
and
> > dependent DLLs and then it executes it.
>
> Valgrind's approach -- dynamically compiling and instrumenting all code
> every time -- is the most convenient for users.  No worrying about whether
> an executable is instrumented or anything.
>
> As for efficiency, it would be possible to have Valgrind save the code it
> generates, so you could reuse it the next time.  But the dynamic
> compilation + instrumentation phase typically only takes up about 10% of
> the execution time for Valgrind (the Memcheck skin, at least) so doing
> this wouldn't help performance much, but it would make the implementation
> more complicated, and possibly make life more difficult for users.
>
> Actually, thinking more, Valgrind's just-in-time approach could has
> another efficiency advantage -- it only instruments the code that gets
> executed.  This is good (especially space-wise) if you only use a small
> fraction of a great big library.
>
> N
>
>
>
>
>
>
> --__--__--
>
> Message: 9
> From: Joshua Moore-Oliva <jo...@ch...>
> To: val...@li...
> Date: Fri, 6 Jun 2003 06:34:13 -0400
> Subject: [Valgrind-users] Problem with libpthread..
>
> For a while I thought this was a glib libpthread prolem..  but when I
noticed
>
> "/usr/lib/valgrind/libpthread.so"
>
> that libpthread was IN valgrind itself...  I think it's got something to
do
> with valgrind.
>
> I created some thread specific data areas... starting at line 57 as per
> valgrinds output I have
>
> /*LINE 57*/if ( pthread_key_create( &global_pthread_base_dir,
free_base_dir )
> != 0 )

>     printf( "File: %s.  Line: %d.  Error initialising key.\n", __FILE__,
> __LINE__ );
>     return 0;
>   }
>
> then before I exit the program I have
>
> if ( pthread_key_delete( global_pthread_base_dir ) != 0 ) {
>     printf( "File: %s.  Line: %d.  Error deleting key.\n", __FILE__,
__LINE__
> );
>     return 0;
>   }
>
>
> When I exit I notice that it appears there is a debug libpthread being
used...
> So I'm thinking the problem is in valgrind debug pthread libraries itself.
>
> Or is it me?
>
> 200 bytes in 1 blocks are still reachable in loss record 1 of 1
> ==17060==    at 0x40215D2B: my_malloc (in /usr/lib/valgrind/libpthread.so)
> ==17060==    by 0x402178A2: get_or_allocate_specifics_ptr (in
> /usr/lib/valgrind/libpthread.so)
> ==17060==    by 0x402179D5: __pthread_key_create (in
> /usr/lib/valgrind/libpthread.so)
> ==17060==    by 0x805612C: main (main.c:57)
> ==17060==    by 0x4028CDC3: __libc_start_main (in /lib/libc-2.3.1.so)
> ==17060==    by 0x804BB90: (within
> /home/chatgris/code/mastermailings/code/daemons/list_manager/list_manager)
>
> Josh
>
>
>
>
> --__--__--
>
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
>
> End of Valgrind-users Digest
>

[Valgrind-users] Problems with XFree-4.3

[Olivier C. <oli...@fr...>]

Hello,

When I used valgrind (cvs head) with a programs which use the XFree-4.3.x
libraries I get the following:

[olivier@snoopy valgrind]$ valgrind -v xcalc
==21680== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==21680== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==21680== Using valgrind-1.9.4, a program supervision framework for x86-linux.
==21680== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==21680== Startup, with flags:
==21680==    --suppressions=/usr/local/lib/valgrind/default.supp
==21680==    -v
==21680== Reading suppressions file: /usr/local/lib/valgrind/default.supp
==21680== Estimated CPU clock rate is 2016 MHz
==21680==
==21680==
==21680== Valgrind detected that your program requires
==21680== the following unimplemented functionality:
==21680==    x86 segment override (SEG=CS) prefix
==21680== This may be because the functionality is hard to implement,
==21680== or because no reasonable program would behave this way,
==21680== or because nobody has yet needed it.  In any case, let me know
==21680== (js...@ac...) and/or try to work around the problem, if you can.
==21680==
==21680== Valgrind has to exit now.  Sorry.  Bye!
==21680==

sched status:

Thread 1: status = Runnable, associated_mx = 0x0, associated_cv = 0x0
==21680== Reading syms from /home/olivier/local/opt/X/bin/xcalc
==21680== Reading syms from /lib/ld-2.2.5.so
==21680== Reading syms from /usr/local/lib/valgrind/vgskin_memcheck.so
==21680== Reading syms from /usr/local/lib/valgrind/valgrind.so
==21680== Reading syms from /home/olivier/local/opt/X/lib/libXaw.so.7.0
==21680== Reading syms from /home/olivier/local/opt/X/lib/libXmu.so.6.2
==21680== Reading syms from /home/olivier/local/opt/X/lib/libXt.so.6.0
==21680== Reading syms from /home/olivier/local/opt/X/lib/libSM.so.6.0
==21680== Reading syms from /home/olivier/local/opt/X/lib/libICE.so.6.3
==21680== Reading syms from /home/olivier/local/opt/X/lib/libXpm.so.4.11
==21680== Reading syms from /home/olivier/local/opt/X/lib/libXext.so.6.4
==21680== Reading syms from /home/olivier/local/opt/X/lib/libX11.so.6.2
==21680== Reading syms from /lib/i686/libm-2.2.5.so
==21680==    object doesn't have a symbol table
==21680==    object doesn't have any debug info
==21680== Reading syms from /lib/i686/libc-2.2.5.so
==21680==    object doesn't have a symbol table
==21680==    object doesn't have any debug info
==21680== Reading syms from /lib/libdl-2.2.5.so
==21680==    object doesn't have a symbol table
==21680==    object doesn't have any debug info
==21680==    at 0x4032BE6C: permalloc (in /home/olivier/local/opt/X/lib/libX11.so.6.2)
==21680==    by 0x4032BFD3: ExpandQuarkTable (in /home/olivier/local/opt/X/lib/libX11.so.6.2)
==21680==    by 0x4032C214: _XrmInternalStringToQuark (in /home/olivier/local/opt/X/lib/libX11.so.6.2)
==21680==    by 0x4032C482: XrmPermStringToQuark (in /home/olivier/local/opt/X/lib/libX11.so.6.2)


If I use the XFree-4.2.1 libs I've not this problem.

Any help welcome ...

Thanks a lot for valgrind, a great software!

Regards, Olivier

Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation

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

On Fri, 6 Jun 2003, Mike Bresnahan wrote:

> > But the dynamic compilation + instrumentation phase typically only
> > takes up about 10% of the execution time for Valgrind (the Memcheck
> > skin, at least) so doing this wouldn't help performance much, but it
> > would make the implementation more complicated, and possibly make life
> > more difficult for users.
>
> I don't understand why it must be more difficult for the user.

If the instrumented version replaces the original version, they don't have
their uninstrumented version anymore.  If the instrumented version is
saved in a second file, they have extra files to deal with.  It's not
necessarily much more difficult for the user.

> Do you know what percentage of time when using the cache profiling skin?

It's hard to give an answer because it can vary quite a bit.  But, as an
example, I just tried bunzip2'ing a 600kb file.  40% of the time was spent
running the instrumented code.  57.5% of the time was spent in the cache
simulation functions.  The time spent compiling and instrumenting was less
than 0.1%.

If you want to know more, you can enable Valgrind's internal profiling by
including the line:

  #include "vg_profile.c"

in a skin (they all have it in there, just commented out).  Recompile, and
use --profile=yes and you get a breakdown of where the time was spent.

> BTW, why are they called "skins"?  It makes it sound like something
> graphical.

Because it's a short name (I didn't want to call them "instrumentation
plug-ins" or somesuch) and I couldn't think of anything better and now it
has stuck :)


> > Actually, thinking more, Valgrind's just-in-time approach could has
> > another efficiency advantage -- it only instruments the code that gets
> > executed.  This is good (especially space-wise) if you only use a small
> > fraction of a great big library.
>
> I agree this is an efficiency gain if you profile the executable only once
> or perhaps a handfull of times.  However the efficiency gain is whiped away
> if you execute the same executable enough times.

Assuming you aren't changing and recompiling the program frequently...

N

Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation

[Mike B. <mbr...@vi...>]

> Valgrind's approach -- dynamically compiling and instrumenting all code
> every time -- is the most convenient for users.  No worrying about whether
> an executable is instrumented or anything.

This is also true of the other approach.  The instrumented code blocks can
be kept in a disk cache which is consulted each time the executable is
executed with profiling enabled.  There's no extra step for the user.  The
user clicks on the same button regardless of whether the application was
previously instrumented.

> As for efficiency, it would be possible to have Valgrind save the code it
> generates, so you could reuse it the next time.

This is what Quantify does.

> But the dynamic
> compilation + instrumentation phase typically only takes up about 10% of
> the execution time for Valgrind (the Memcheck skin, at least) so doing
> this wouldn't help performance much, but it would make the implementation
> more complicated, and possibly make life more difficult for users.

I don't understand why it must be more difficult for the user.

Do you know what percentage of time when using the cache profiling skin?

BTW, why are they called "skins"?  It makes it sound like something
graphical.

> Actually, thinking more, Valgrind's just-in-time approach could has
> another efficiency advantage -- it only instruments the code that gets
> executed.  This is good (especially space-wise) if you only use a small
> fraction of a great big library.

I agree this is an efficiency gain if you profile the executable only once
or perhaps a handfull of times.  However the efficiency gain is whiped away
if you execute the same executable enough times.

In any case, if it's only a 10% difference in performance, I'm not going to
worry about too much.

Thanks for the responses.

Mike Bresnahan

Re: [Valgrind-users] Problem with libpthread..

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

On Fri, 6 Jun 2003, Joshua Moore-Oliva wrote:

> When I exit I notice that it appears there is a debug libpthread being used...
> So I'm thinking the problem is in valgrind debug pthread libraries itself.
>
> 200 bytes in 1 blocks are still reachable in loss record 1 of 1
> ==17060==    at 0x40215D2B: my_malloc (in /usr/lib/valgrind/libpthread.so)
> ==17060==    by 0x402178A2: get_or_allocate_specifics_ptr (in
> /usr/lib/valgrind/libpthread.so)
> ==17060==    by 0x402179D5: __pthread_key_create (in
> /usr/lib/valgrind/libpthread.so)
> ==17060==    by 0x805612C: main (main.c:57)
> ==17060==    by 0x4028CDC3: __libc_start_main (in /lib/libc-2.3.1.so)
> ==17060==    by 0x804BB90: (within
> /home/chatgris/code/mastermailings/code/daemons/list_manager/list_manager)

It's a leak in Valgrind's pthreads implementation, unfortunately.  We
added a suppression that will go into the next release -- actually fixing
the leak proved too difficult :(

So, you can ignore it.  If it's bugging you, you can use this suppression:

{
   my_malloc/get_or_allocate_specifics_ptr/__pthread_key_create(Leak)
   Memcheck:Leak
   fun:my_malloc
   fun:get_or_allocate_specifics_ptr
   fun:__pthread_key_create
}


N

[Valgrind-users] Problem with libpthread..

[Joshua Moore-O. <jo...@ch...>]

For a while I thought this was a glib libpthread prolem..  but when I noticed

"/usr/lib/valgrind/libpthread.so"

that libpthread was IN valgrind itself...  I think it's got something to do 
with valgrind.

I created some thread specific data areas... starting at line 57 as per 
valgrinds output I have

/*LINE 57*/if ( pthread_key_create( &global_pthread_base_dir, free_base_dir ) 
!= 0 ) { 
    printf( "File: %s.  Line: %d.  Error initialising key.\n", __FILE__, 
__LINE__ );
    return 0;
  }

then before I exit the program I have

if ( pthread_key_delete( global_pthread_base_dir ) != 0 ) {
    printf( "File: %s.  Line: %d.  Error deleting key.\n", __FILE__, __LINE__ 
);
    return 0;
  }


When I exit I notice that it appears there is a debug libpthread being used...  
So I'm thinking the problem is in valgrind debug pthread libraries itself.

Or is it me?

200 bytes in 1 blocks are still reachable in loss record 1 of 1
==17060==    at 0x40215D2B: my_malloc (in /usr/lib/valgrind/libpthread.so)
==17060==    by 0x402178A2: get_or_allocate_specifics_ptr (in 
/usr/lib/valgrind/libpthread.so)
==17060==    by 0x402179D5: __pthread_key_create (in 
/usr/lib/valgrind/libpthread.so)
==17060==    by 0x805612C: main (main.c:57)
==17060==    by 0x4028CDC3: __libc_start_main (in /lib/libc-2.3.1.so)
==17060==    by 0x804BB90: (within 
/home/chatgris/code/mastermailings/code/daemons/list_manager/list_manager)

Josh

Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation

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

On Thu, 5 Jun 2003, Mike Bresnahan wrote:

> Perhaps I misunderstand how valgrind works.  I have the understanding that,
> using the synthetic CPU, valgrind instruments the application on the fly and
> stores the instrumented code blocks in a cache.  The author describes this
> process here http://developer.kde.org/~sewardj/docs-1.9.5/mc_techdocs.html.
>
> Do I misunderstand?

You are right, Valgrind instruments the app dynamically.

I think when Alex said Valgrind doesn't "instrument" anything, he meant
that you don't have to do anything explicit, in a separate step.

> Note that Quanitfy for Windows does not require a relink.  You just point it
> at an executable and off it goes.  First it instruments the executable and
> dependent DLLs and then it executes it.

Valgrind's approach -- dynamically compiling and instrumenting all code
every time -- is the most convenient for users.  No worrying about whether
an executable is instrumented or anything.

As for efficiency, it would be possible to have Valgrind save the code it
generates, so you could reuse it the next time.  But the dynamic
compilation + instrumentation phase typically only takes up about 10% of
the execution time for Valgrind (the Memcheck skin, at least) so doing
this wouldn't help performance much, but it would make the implementation
more complicated, and possibly make life more difficult for users.

Actually, thinking more, Valgrind's just-in-time approach could has
another efficiency advantage -- it only instruments the code that gets
executed.  This is good (especially space-wise) if you only use a small
fraction of a great big library.

N

Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation

[Mike B. <mbr...@vi...>]

Perhaps I misunderstand how valgrind works.  I have the understanding that,
using the synthetic CPU, valgrind instruments the application on the fly and
stores the instrumented code blocks in a cache.  The author describes this
process here http://developer.kde.org/~sewardj/docs-1.9.5/mc_techdocs.html.

Do I misunderstand?

Note that Quanitfy for Windows does not require a relink.  You just point it
at an executable and off it goes.  First it instruments the executable and
dependent DLLs and then it executes it.  The UNIX version requires a
relink - or at least it did when I last used it in the mid-1990's on HPUX.

Mike Bresnahan
----- Original Message ----- 
From: "Alex Ivershen" <ale...@in...>
To: "Mike Bresnahan" <mbr...@vi...>
Cc: <Val...@li...>
Sent: Thursday, June 05, 2003 5:41 PM
Subject: Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation


> Valgrind, unlike Rational suite tools, does not "instrument" anything.
That's the beauty of it - you don't need to recompile (or in case ot
Quantify re-link) the application.  The difference is that Rational tools
embed extra code inside your object files and libraries - for memory or
performance profiling. As a result, executable size, shared libraries sizes
are huge and executiion suffers greatly (esp. with purify). Valgrind, on the
other hand, runs your application on a synthetic CPU, all the machine
instructions of your app are executed by Valgrind on this CPU and
memory/performance profiling is done there, not in your app code.  As far as
Quantify comparison, cachegrind sking gives you much more information - e.g.
Quantify does not report cache usage profile.
> Last but not least - Valgrind is free, has MUCH better developer support,
and is updated more frequently.
> Downside - only runs on x86 Linux, exactly because of synthetic CPU -
porting it to other platforms is too much work, so developers chose the most
popular platform.
>
> Regards,
> Alex

Re: [Valgrind-users] Pre-instrumented vs JIT instrumentation

[Alex I. <ale...@in...>]

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Valgrind, unlike Rational suite tools, does not "instrument" anything.&nbsp;
That's the beauty of it - you don't need to recompile (or in case ot Quantify
re-link) the application.&nbsp; The difference is that Rational tools embed
extra code inside your object files and libraries - for memory or performance
profiling. As a result, executable size, shared libraries sizes are huge
and executiion suffers greatly (esp. with purify). Valgrind, on the other
hand, runs your application on a synthetic CPU, all the machine instructions
of your app are executed by Valgrind on this CPU and memory/performance
profiling is done there, not in your app code.&nbsp; As far as Quantify
comparison, cachegrind sking gives you much more information - e.g. Quantify
does not report cache usage profile.
<p>Last but not least - Valgrind is free, has MUCH&nbsp;better developer
support, and is updated more frequently.
<br>Downside - only runs on x86 Linux, exactly because of synthetic CPU
- porting it to other platforms is too much work, so developers chose the
most popular platform.
<p>Regards,
<br>Alex
<p>Mike Bresnahan wrote:
<blockquote TYPE=CITE>I am new to valgrind, but I have used Rational Quantify.&nbsp;
Excuse if this is
<br>a FAQ, but I could not find anything in the FAQ nor in the mailing
list
<br>archive.
<p>I am curious why valgrind chooses to instrument on-the-fly every time
the
<br>application is executed rather than instrumenting the application ahead
of
<br>time and reexecuting the same instrumented executable each time, a
la
<br>Quantify.&nbsp; To my perhaps naive mind it seems like instrumenting
on-the-fly
<br>is less efficient.&nbsp; Can someone lend some insight?
<p>Mike
<p>-------------------------------------------------------
<br>This SF.net email is sponsored by:&nbsp; Etnus, makers of TotalView,
The best
<br>thread debugger on the planet. Designed with thread debugging features
<br>you've never dreamed of, try TotalView 6 free at www.etnus.com.
<br>_______________________________________________
<br>Valgrind-users mailing list
<br>Val...@li...
<br><a href="https://lists.sourceforge.net/lists/listinfo/valgrind-users">https://lists.sourceforge.net/lists/listinfo/valgrind-users</a></blockquote>

<pre>--&nbsp;
Alex G. Ivershen&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Inet Technologies, Inc.
Network Products Dept.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 1500 N. Greenville Ave.
Inet Technologies Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Richardson, TX 75081
Phone: +1-469-330-4295&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; USA

"Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd&nbsp;
all be running around in darkened rooms, munching magic pills and listening to
repetitive electronic music." -- Kristian Wilson, Nintendo, Inc</pre>
&nbsp;</html>

[Valgrind-users] Pre-instrumented vs JIT instrumentation

[Mike B. <mbr...@vi...>]

I am new to valgrind, but I have used Rational Quantify.  Excuse if this is
a FAQ, but I could not find anything in the FAQ nor in the mailing list
archive.

I am curious why valgrind chooses to instrument on-the-fly every time the
application is executed rather than instrumenting the application ahead of
time and reexecuting the same instrumented executable each time, a la
Quantify.  To my perhaps naive mind it seems like instrumenting on-the-fly
is less efficient.  Can someone lend some insight?

Mike

Re: [Valgrind-users] __builtin_new and its buddies

[Alex I. <ale...@in...>]

Sm9zZWYsDQoNCkkgdGhhbmsgeW91IHNvIG11Y2ggZm9yIHlvdXIgYXNzaXRhbmNlISBDbGVh
cmVkIHVwIHRoaW5ncyBmb3IgbWUgcXVpdGUgYSBiaXQuDQpXaGF0IEkgcmVzb3J0ZWQgdG8g
ZG9pbmcgaXMgYnVpbGRpbmcgYSBzaGFyZWQgbGlic3RkYysrIGxpYnJhcnkgYW5kIGZvcmNl
DQppbi1ob3VzZSBidWlsZHMgdG8gdXNlIHRoZSBzaGFyZWQgbGlicmFyeSBhbmQgZXh0ZXJu
YWwgcmVsZWFzZXMgdG8gbGluaw0Kc3RhdGljYWxseS4gIFZhbGdyaW5kIGlzIHdvcmtpbmcg
cGVyZmVjdGx5IHdpdGggc2hhcmVkIGxpYnN0ZGMrKy4gTWlnaHQgYmUgd29ydGgNCmFkZGlu
ZyB0byBWYWxncmluZCBGQVE/DQoNClRoYW5rcyBhZ2FpbiEgUmVnYXJkcywNCkFsZXgNCg0K
DQpKb3NlZiBXZWlkZW5kb3JmZXIgd3JvdGU6DQoNCj4gT24gVGh1cnNkYXkgMDUgSnVuZSAy
MDAzIDAwOjUyLCBBbGV4IEl2ZXJzaGVuIHdyb3RlOg0KPiA+IDwhZG9jdHlwZSBodG1sIHB1
YmxpYyAiLS8vdzNjLy9kdGQgaHRtbCA0LjAgdHJhbnNpdGlvbmFsLy9lbiI+DQo+ID4gPGh0
bWw+DQo+ID4gR2VudGxlbWVuLA0KPiA+IDxwPkkgYW0gc3RpbGwgaGF2aW5nIGlzc3VlcyB3
aXRoIF9fYnVpbHRpbl9uZXcgbm90IGJlaW5nIGludGVyY2VwdGVkIGJ5DQo+ID4gVmFsZ3Jp
bmQuJm5ic3A7IEplcmVteSBGaXR6aGFyZGluZ2UgZ2F2ZSBtZSBzb21lIHN1Z2dlc3Rpb25z
LCBidXQgaXQgZGlkDQo+ID4gbm90IHNvbHZlIHRoZSBpc3N1ZS4gSGVyZSBpcyB0aGUgcHJv
YmxlbTogd2hlbiBJIGFtIGNvbXBsaW5nIGNlcnRhaW4NCj4gPiBjbGFzc2VzLCB0aGUgY29t
cGlsZXIgZ2VuZXJhdGVzIHJlZmVyZW5jZXMgdG8gX19idWlsdGluX25ldyAodmVjX25ldywN
Cj4gPiBkZWxldGUsIHZlY19kZWxldGUpIGluIHRoZSBvYmplY3QgZmlsZS4mbmJzcDsgV2hl
biB0aGlzIG9iamVjdCBmaWxlIGlzDQo+ID4gbGlua2VkIGludG8gZXhlY3V0YWJsZSwgdGhl
IGNvbXBpbGVyIHJlc29sdmVzIHRoZSBfX2J1aWx0aW4qIHJlZmVyZW5jZXMNCj4gPiBmcm9t
IGxpYmdjYy5hLCB3aGVyZSB0aGV5IGFyZSBkZWZpbmVkIGFzICJXIiBzeW1ib2xzLg0KPiA+
IDxwPkFzIGEgcmVzdWx0LCZuYnNwOyBWYWxncmluZCBkb2VzIE5PVCBpbnRlcmNlcHQgdGhv
c2UgX19idWlsdGluKg0KPiA+IGZ1bmN0aW9ucywgYW5kIG9ubHkgY2F0Y2hlcyBtYWxsb2Mo
KSBhbmQgZnJlZSgpIGNhbGxzIHdoZW4gdGhlc2UgY2xhc3Nlcw0KPiA+IGFyZSB1c2VkLiBB
cyB5b3UgY2FuIGltYWdpbmUsIGEgc3dhcm0gb2YgbXVzbWF0Y2hlZCBmcmVlL2RlbGV0ZS9k
ZWxldGVbXSBpcw0KPg0KPiBZb3VyIG9iamVjdCBmaWxlcyBzZWVtIHRvIGJlIGZpbmUuDQo+
IFRoZSBwcm9ibGVtIGlzLCB0aGF0IHRoZSBzdGF0aWMgbGluayBwcm9jZXNzIHNob3VsZG4n
dCByZXNvbHZlIF9fYnVpbHRpbl9uZXcsDQo+IGkuZS4gdGhlIGxpYmdjYy5hIHlvdSBtZW50
aW9uIHNlZW1zIHRvIGJlIHdyb25nLCBpZiBpdCByZWFsbHkgZGVmaW5lcw0KPiBfX2J1aWx0
aW5fbmV3IHN0YXRpY2FsbHkuIFBlcmhhcHMgdGhpcyBmaWxlIHNob3VsZG4ndCBiZSBsaW5r
ZWQgaW4gb3IgaXMgZnJvbQ0KPiBhIHdyb25nIGNvbXBpbGVyIHZlcnNpb24/IE9yIHlvdSBk
byBzb21lIHBhcnRpYWwgc3RhdGljIGxpbmtpbmcuIFdoYXQncyB5b3VyDQo+IGxpbmsgY29t
bWFuZCBsaW5lPw0KPg0KPiBJIGp1c3QgY2hlY2tlZCB3aXRoIG15IG93biBpbnN0YWxsYXRp
b24gb2YgR0NDIDIuOTUuMyAoU3VzZTguMSkuDQo+IElmIEkgY29tcGlsZSB5b3VyIENsYXNz
ZXMyLjk1LjMubyB3aXRoIGEgZHVtbXkgbWFpbigpLCBpdCBsaW5rcyBmaW5lLCBhbmQgaW4N
Cj4gdGhlIHJlc3VsdGluZyBleGVjdXRhYmxlLCB0aGVyZSAqaXMqIHRoZSBzeW1ib2wgX19i
dWlsdGluX25ldywgc28gdGhlcmUgd2lsbA0KPiBiZSBubyBwcm9ibGVtIHdpdGggdmFsZ3Jp
bmQgPyE/DQo+IFVzdWFsbHksICJfX2J1aWx0aW5fbmV3IiBpcyBkZWZpbmVkIGluICJsaWJz
dGRjKystbGliYzYuMi0yLnNvLjMiIGFuZCB3aWxsIGJlDQo+IGxpbmtlZCBpbiBieSB0aGUg
cnVudGltZSBsaWJyYXJ5Lg0KPg0KPiBKb3NlZg0KDQotLQ0KQWxleCBHLiBJdmVyc2hlbiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICBJbmV0IFRlY2hub2xvZ2llcywgSW5jLg0KTmV0
d29yayBQcm9kdWN0cyBEZXB0LiAgICAgICAgICAgICAgICAgICAgICAxNTAwIE4uIEdyZWVu
dmlsbGUgQXZlLg0KSW5ldCBUZWNobm9sb2dpZXMgSW5jLiAgICAgICAgICAgICAgICAgICAg
ICBSaWNoYXJkc29uLCBUWCA3NTA4MQ0KUGhvbmU6ICsxLTQ2OS0zMzAtNDI5NSAgICAgICAg
ICAgICAgICAgICAgICBVU0ENCg==

Re: [Valgrind-users] __builtin_new and its buddies

[Josef W. <Jos...@gm...>]

On Thursday 05 June 2003 16:34, Alex Ivershen wrote:
> Josef,
>
> With the test classes, I am linking simply as "g++ -o TEST main.o
> Classes2.95.3.o". The libgcc.a library seems to be correct to me - that was
> built along with the compiler and never gave me any grief.  You are saiying
> that " Usually, __builtin_new is defined in "libstdc++-libc6.2-2.so.3" and
> will be linked in by the runtime library." - however, libstdc++ in my
> installation is STATIC, there is a specific requirement not to use any

Ok. So this is the culprit, and makes sense:
If the (static) linker detects a symbol in different libraries, it prefers 
symbols from shared libraries and lets the runtime linker do the resolving 
(this at least seems to be true because __builtin_new is defined as weak (W) 
in libgcc.a).

Then your requirements (only static libs from the compiler) effectively 
prohibit the use of Valgrind for you.

> shared compiler libraries. So, in static libstdc++ __builtin_new are "U"
> symbols. The only place the program can pull the definitions from is
> libgcc.a.  I tried
> "-nostdlibraries" swich to the compiler to prevent him from pulling it by
> default, but then, of course, the app won't link, citing  unresolved
> symbols.
>
> Now, when you do "nm" on your test application, what is the symbol type for
> "__builtin_new"?  And I am guessing that "ldd" shows dependency on
> "libstdc++-libc6.2-2.so.3" - the application expects to resolve it at
> run-time from libstdc++ and Valgrind has a chance to intercept everyting,

Yes.

> right?  So, the bottom line seems to be that if I use static libstdc++, I
> am screwed? Ugh ...

Sure. You can't use Valgrind with static linked binaries, and that seems to 
hold true with even partial static binaries (as you don't have a 
"libstdc++-libc6.2-2.so.3"). 

But perhaps you can link in a shared library of your own with __builtin_new, 
calling malloc. At least this would allow to run the application with 
Valgrind, or even better: Put valgrind.so into your link line!

Josef

>
> Alex
>
> Josef Weidendorfer wrote:
> > On Thursday 05 June 2003 00:52, Alex Ivershen wrote:
> > > <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
> > > <html>
> > > Gentlemen,
> > > <p>I am still having issues with __builtin_new not being intercepted by
> > > Valgrind.&nbsp; Jeremy Fitzhardinge gave me some suggestions, but it
> > > did not solve the issue. Here is the problem: when I am compling
> > > certain classes, the compiler generates references to __builtin_new
> > > (vec_new, delete, vec_delete) in the object file.&nbsp; When this
> > > object file is linked into executable, the compiler resolves the
> > > __builtin* references from libgcc.a, where they are defined as "W"
> > > symbols.
> > > <p>As a result,&nbsp; Valgrind does NOT intercept those __builtin*
> > > functions, and only catches malloc() and free() calls when these
> > > classes are used. As you can imagine, a swarm of musmatched
> > > free/delete/delete[] is
> >
> > Your object files seem to be fine.
> > The problem is, that the static link process shouldn't resolve
> > __builtin_new, i.e. the libgcc.a you mention seems to be wrong, if it
> > really defines __builtin_new statically. Perhaps this file shouldn't be
> > linked in or is from a wrong compiler version? Or you do some partial
> > static linking. What's your link command line?
> >
> > I just checked with my own installation of GCC 2.95.3 (Suse8.1).
> > If I compile your Classes2.95.3.o with a dummy main(), it links fine, and
> > in the resulting executable, there *is* the symbol __builtin_new, so
> > there will be no problem with valgrind ?!?
> > Usually, "__builtin_new" is defined in "libstdc++-libc6.2-2.so.3" and
> > will be linked in by the runtime library.
> >
> > Josef
>
> --
> Alex G. Ivershen                            Inet Technologies, Inc.
> Network Products Dept.                      1500 N. Greenville Ave.
> Inet Technologies Inc.                      Richardson, TX 75081
> Phone: +1-469-330-4295                      USA
>
> "Computer games don't affect kids; I mean if Pac-Man affected us as kids,
> we'd all be running around in darkened rooms, munching magic pills and
> listening to repetitive electronic music." -- Kristian Wilson, Nintendo,
> Inc