valgrind-users

[Valgrind-users] Using valgrind on a system with nvidia

[Paul H. <pa...@ha...>]

My company bought a new Linux system so I can run valgrind faster.  The
purchasing department doesn't understand Linux, so it came with Windows XP
installed and a high end Nvidia graphics card.  Getting rid of Windows XP
was easy, but I think I'm stuck with the Nvidia card.  The "nv" driver
mostly works, but text was getting messed up when xterms scrolled.  So I
tried the drivers from Nvidia.  Now my xterms worked, but valgrind stopped
working.

As many are painfully aware, the problem isn't the hardware, it is the
drivers.  Specifically it's /usr/lib/libGL.so.1.0.4349 and libraries it
pulls in.

My system is mostly Debian unstable.  After foolishly installing the
Nvidia drivers, I got valgrind to work again by typing:

  apt-get install --reinstall xlibmesa3-gl

This puts back the /usr/X11R6/lib/libGL.so.1.2 that the Nvidia install
script removed.  The nvidia stuff is libGL.so.1.0 and the mesa3-gl is
 .1.2, so I can probably play with version numbers to get either library.
The mesa library is fast enough for me, since I spend far more time
working on the CAD program than I do actually running the CAD program with
large models. Most importantly, my xterms don't get messed up when I
scroll them.

I've tried valgrind 1.0.4, 1.9.5 and the CVS tip (why does it call itself
1.9.4?), and they all work on this somewhat bastardized OpenGL
configuration.

Performance with the Mesa libGL and the "nvidia" driver is much better
than it was with the "nv" driver.  (That might just mean I screwed up the
"nv" driver configuration.)

I spent some time playing with LD_LIBRARY_PATH to get different libraries,
this worked, but it looked like I'd have to spend time maintaining
multiple suppression files, since our older Linux systems aren't cursed
with the Nvidia hardware.

--
Paul Haas, pa...@Ha...

Re: [Valgrind-users] Using valgrind on a system with nvidia

[Paul Cheyrou-l. <Pau...@in...>]

I use both on the same linux system :

1. install latest nvidia driver
2. download Mesa source from mesa3d.org
3. compile and install Mesa from sources (make install should install it in /usr/local/lib/)
(if you're coding some opengl try configure --enable-warn --enable-trace, 
you'll get some VERY useful information)

Then, when you want to use Mesa, 
just launch a shell command 
export LD_LIBRARY_PATH=/usr/local/lib
and launch apps. (Valgrind included)

When you want to use hardware opengl,
export LD_LIBRARY_PATH=

Then you can test code with both, and debug with Mesa, wich is easier.

-Paul

Re: [Valgrind-users] Using valgrind on a system with nvidia

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

The non-working of valgrind with nvidia drivers might go away when
we finally get around to implementing SSE/SSE2 instructions, which 
we hope will happen soon.  

However, NVidia also noticed this it seems, and the "latest" drivers
(don't ask me what version, I don't use them) come with this text

        DISABLING CPU SPECIFIC FEATURES

        Setting the environment variable __GL_FORCE_GENERIC_CPU to a
        non-zero value will inhibit the use of CPU specific features
        such as MMX, SSE, or 3DNOW!.  Use of this option may result in
        performance loss.  This option may be useful in conjunction with
        software such as the Valgrind memory debugger.

__GL_FORCE_GENERIC_CPU=1 valgrind ... whatever ...

apparently does work.  Great stuff.  Ah yes, version 4349 according
to Sylvain's just-arrived message.

J


On Friday 11 April 2003 5:36 am, Paul Cheyrou-lagreze wrote:
> I use both on the same linux system :
>
> 1. install latest nvidia driver
> 2. download Mesa source from mesa3d.org
> 3. compile and install Mesa from sources (make install should install it in
> /usr/local/lib/) (if you're coding some opengl try configure --enable-warn
> --enable-trace, you'll get some VERY useful information)
>
> Then, when you want to use Mesa,
> just launch a shell command
> export LD_LIBRARY_PATH=/usr/local/lib
> and launch apps. (Valgrind included)
>
> When you want to use hardware opengl,
> export LD_LIBRARY_PATH=
>
> Then you can test code with both, and debug with Mesa, wich is easier.
>
> -Paul
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] periodical flush of cachegrind.out

[<cha...@ya...>]

 

 Hi,

 Im wondering if its possible to cachegrind to
periodically dump a partial cachegrind.out file, so
one can check the profile statistics without finishing
the application


 Greetings


------------
¡Internet GRATIS es Yahoo! Conexión!
Usuario "yahoo", contraseña "yahoo". 
Desde Buenos Aires, 4004-1010.
Otras ciudades: http://conexion.yahoo.com.ar/avanzados.html

Re: [Valgrind-users] periodical flush of cachegrind.out

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

I think Josef Weidendorfer's kcachegrind patches might be able to
do this, or something like it.  See here:

http://kcachegrind.sourceforge.net/

J

On Friday 11 April 2003 8:15 pm, Charlls Quarra wrote:
>  Hi,
>
>  Im wondering if its possible to cachegrind to
> periodically dump a partial cachegrind.out file, so
> one can check the profile statistics without finishing
> the application
>
>
>  Greetings
>
>
> ------------
> ¡Internet GRATIS es Yahoo! Conexión!
> Usuario "yahoo", contraseña "yahoo".
> Desde Buenos Aires, 4004-1010.
> Otras ciudades: http://conexion.yahoo.com.ar/avanzados.html
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
> for complex code. Debugging C/C++ programs can leave you feeling lost and
> disoriented. TotalView can help you find your way. Available on major UNIX
> and Linux platforms. Try it free. www.etnus.com
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

Re: [Valgrind-users] periodical flush of cachegrind.out

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

On Friday 11 April 2003 22:15, Charlls Quarra wrote:
>  Hi,
>
>  Im wondering if its possible to cachegrind to
> periodically dump a partial cachegrind.out file, so
> one can check the profile statistics without finishing
> the application

Hi Charlls,

take a look at my call-tree skin (I think I should rename it to callgraph, 
shouldn't I?) at kcachegrind.sf.net. The newest version 0.2.93 allows for

1) ad hoc dumping ("touch cachegrind.cmd" while running). This method is 
"supported" with auto-reloading after the dump in KCachegrind by clicking on 
a toolbar button.

2) periodic dumping every <count> basic blocks (--dumps=<count>).

3) dumping at enter/leave of all functions whose name starts with <funcprefix> 
(--dump-before=<funcprefix>/--dump-after=<funcprefix>). I choose the prefix 
method so with C++ you don't have to specify full signatures. You can specify 
this option multiple times.

4) program controlled dumping: "#include <valgrind/calltree.h>" into your 
source and add "CALLTREE_DUMP_STATS;" when you want a dump to happen.

If you are running a multi-threaded application and specify 
"--dump-threads=yes", every thread will be profiled on its own and will 
create its own profile dump. Thus, (3) and (4) will only generate one dump of 
the currently running thread. With (1) and (2), you will get multiple dumps 
(one for each thread) on a dump request. 

The generated dump files get names

	cachegrind.out.<pid>[.<part>][-<threadID>]

where <pid> is the PID of the running program, <part> is a number incremented 
on each dump (".<part>" is skipped for the dump at program termination), 
<threadID> is a thread identification.
When your program changes the current working directory while running, the 
dump files will get spread out into different directory. This can be avoided 
by specifying a dump file base name with an absolute path with 
"--base=/tmp/cachegrind.out".

You can control for which part of your program you want to collect event costs 
by using --toggle-collect=<funcprefix>. This will toggle the collection state 
on entering and leaving a function. When specifying this option, the default 
collecting state at programm start is "off". Thus, only events happing while 
running inside of <funcprefix> will be collected. Recursive function calls of 
<funcprefix> don't influence collecting at all.

Note that cache simulation still will be done all the time to be usefull. 
Thus, you don't have any speedup while collection state is off. But you can 
switch off cache simulation with "--simulate-cache=no". This will only give 
instruction read accesses and the callgraph tracing. But it significantly 
speeds up the profiling typically by more than a factor of 2.

There is an option to ignore calls to a function with 
"--fn-skip=<funcprefix>". E.g. you usually don't want to see the trampoline 
functions in the PLT sections for calls to functions in shared libs. You can 
see the difference if you profile with "--skip-plt=no". If a call is ignored, 
cost events happening will be attached to the enclosing function.

The remaining options are used to avoid cycles in profile data.
* if you have a recursive function, you can distinguish the first 10 recursion 
levels by specifying "--fn-recursion10=<funcprefix>". Or for all functions 
with "fn-recursion=10", but this will give you *much* bigger profile dumps.
In the profile data, you will see the recursion levels of "func" as the 
different functions with names "func", "func'2", "func'3" and so on.
* if you have call chains "A > B > C" and "A > C > B" in your program, you 
usually get a "false" cycle "B <> C". Use "--fn-caller2=B --fn-caller2=C", 
and functions "B" and "C" will be treated as different functions depending on 
the direct caller. Using the apostrophe for appending this "context" to the 
function name, you get "A > B'A > C'B" and "A > C'A > B'C", and there will be 
no cycle. Use "--fn-callers=3" to get a 2-caller depencendy for *all* 
functions. Again, this will multiplicate the profile data size.

Cheers,
Josef

Re: [Valgrind-users] Using valgrind on a system with nvidia

[Sylvain J. <syl...@m4...>]

You can disable the use of MMX/SSE/whatever in the latest nvidia driver=20
(4349) by setting the __GL_FORCE_GENERIC_CPU environment variable to a=20
non-zero value

=46rom the readme:

DISABLING CPU SPECIFIC FEATURES

Setting the environment variable __GL_FORCE_GENERIC_CPU to a non-zero
value will inhibit the use of CPU specific features such as MMX, SSE,
or 3DNOW!.  Use of this option may result in performance loss.  This
option may be useful in conjunction with software such as the Valgrind
memory debugger.
=2D-=20
Sylvain Joyeux