valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] openoffice and valgrind1.9.6 - strange problems. Using rh8

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

Julian Seward (jseward at acm.org) wrote:
> Hi.  First off, I think OpenOffice is an important project
> and am pleased to hear someone is valgrinding it.  OO is my
> biggest, most hairy test case.  If it's possible, I'd like to
> help the OOo developers be in the position where they routinely
> valgrindify OOo, in the same way that the KDE and Gnome folks 
> use it routinely.

Excellent!  I'm hoping to use it quickly in the next few
days to help make OpenOffice 1.1 beta more solid.  I don't
know if the openoffice developers are using it yet; I'm
just a gadfly who got a bee in his bonnet about a backlog
of untriaged bugs in the openoffice bug tracking system, and
jumped in to help sort through them and mark the interesting
ones for the developers to work on.

> I don't a RH8 box to repro this on.  But I have just tried
> gdb attach/detach on SuSE 8.2 on the OOo 1.0.2 they supply,
> and that works fine using the valgrind cvs head.  I did it a
> bit different from you, perhaps:
> 
>    LD_LIBRARY_PATH=/opt/OpenOffice.org/program    \
>    ./Inst/bin/valgrind -v -v --skin=addrcheck     \
>    --gdb-attach=yes  /opt/OpenOffice.org/program/soffice.bin
> 
> I did all that directly on the command line, no shell script
> or anything.  Perhaps your shell script ./soffice-valgrind.sh
> is causing a problem?  Can you try something equivalent to the
> above?

Thanks for that nice short line.  (I had been clumsily editing
the soffice script without bothering to understand it.)  However,
I get the same results with that as with my script.
Also, your errno patch didn't have any impact on the
strange problem I had running valgrind 1.9.6 on Red Hat 8,
just as you expected.
The good news is, I verified that valgrind 1.9.6 on Red Hat 7.2
does run openoffice1.1beta just fine.
I believe I'm unstuck now, and will continue with OO on valgrind
next chance I get.

> The following is a question re OO on V.  With the help of Michael
> Meeks at Ximian, I did manage to build from source various cvs
> branches of OO (cws_srx644_ooo11beta, in the end) and valgrinded
> them.  What I noticed was that (1) the number of mallocs/frees
> reported by V was surprisingly low, compared with 1.0.2, 
> and (2) all the buffer-overrun errors had disappeared.  And so
> I wondered if OO had moved to using some kind of internal
> allocator which V cannot 'see' ?  Alternatively of course all
> those bugs have been fixed.

No idea - but I'll pass the question on to de...@op....
- Dan


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

Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

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

> However... I managed to recreate the exact same problem with another
> testcase. The new testcase contains the same code, but runs in a
> different thread. Script is attached.

Er, yes.  There's definitely some still wrong with errno handling
on both my glibc-2.3.2 systems.  The attached test program I made
doesn't work properly -- the perror calls print different stuff when 
running on V.  I'll look into it more tomorrow night.  The strange
thing is the numbers returned by the errno uses are right, it's just
that when perror reads errno it gets junk.

Nick, can you lmk if it works on R H 7.1?  Thx,

J




#include <pthread.h>
#include <stdio.h>
#include <errno.h>

void* thr2 ( void* v )
{
  FILE* f = fopen("bogus2", "r");
  printf("f2 = %p, errno2 = %d\n", f, errno);
  perror("wurble2");
  return NULL;
}

void* thr3 ( void* v )
{
  FILE* f = fopen("bogus3", "r");
  printf("f3 = %p, errno3 = %d\n", f, errno);
  perror("wurble3");
  return NULL;
}

int main ( void )
{
  FILE* f;
  pthread_t tid2, tid3;
  pthread_create(&tid2, NULL, &thr2, NULL);
  pthread_create(&tid3, NULL, &thr3, NULL);
  f = fopen("bogus", "r");
  printf("f1 = %p, errno1 = %d\n", f, errno);
  perror("wurble1");
  pthread_join(tid2, NULL);
  pthread_join(tid3, NULL);
  return 0;
}

Re: [Valgrind-users] openoffice and valgrind1.9.6 - strange problems. Using rh8.

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

Hi.  First off, I think OpenOffice is an important project
and am pleased to hear someone is valgrinding it.  OO is my
biggest, most hairy test case.  If it's possible, I'd like to
help the OOo developers be in the position where they routinely
valgrindify OOo, in the same way that the KDE and Gnome folks 
use it routinely.

I don't a RH8 box to repro this on.  But I have just tried
gdb attach/detach on SuSE 8.2 on the OOo 1.0.2 they supply,
and that works fine using the valgrind cvs head.  I did it a
bit different from you, perhaps:

   LD_LIBRARY_PATH=/opt/OpenOffice.org/program    \
   ./Inst/bin/valgrind -v -v --skin=addrcheck     \
   --gdb-attach=yes  /opt/OpenOffice.org/program/soffice.bin

I did all that directly on the command line, no shell script
or anything.  Perhaps your shell script ./soffice-valgrind.sh
is causing a problem?  Can you try something equivalent to the
above?

I fixed a threading problem that 1.9.6 has with glibc >= 2.3.2,
which caused it to mis-handle errno, but IIRC RH8 is glibc-2.3.1
and the errno problems didn't seem to afflict it.  Nevertheless
I attach a patch which fixes the problem and you should apply
it to your 1.9.6.  It'll be rolled into 1.9.7.

Let me know the outcome of the above.

The following is a question re OO on V.  With the help of Michael
Meeks at Ximian, I did manage to build from source various cvs
branches of OO (cws_srx644_ooo11beta, in the end) and valgrinded
them.  What I noticed was that (1) the number of mallocs/frees
reported by V was surprisingly low, compared with 1.0.2, 
and (2) all the buffer-overrun errors had disappeared.  And so
I wondered if OO had moved to using some kind of internal
allocator which V cannot 'see' ?  Alternatively of course all
those bugs have been fixed.

J




On Sunday 11 May 2003 9:13 pm, Dan Kegel wrote:
> Hi, I'm using valgrind 1.9.6 on redhat 8.0 with OpenOffice.
> It seems to work fine with no options, but if I turn on
> --gdb-attach=yes, I don't get what I expect.  On the
> first error, it asks me nicely if I want to run gdb,
> and it does start gdb, but here's what I see:
>
> ==18736== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y
> ==18736== starting GDB with cmd: /usr/bin/gdb -nw /proc/18736/exe 18736
> GNU gdb Red Hat Linux (5.2.1-4)
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are welcome to change it and/or distribute copies of it under certain
> conditions. Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "i386-redhat-linux"...
> (no debugging symbols found)...
> Attaching to program: /opt/OpenOffice.org644/program/soffice.bin, process
> 18736 Reading symbols from
> /usr/local/lib/valgrind/vgskin_memcheck.so...done. Loaded symbols for
> /usr/local/lib/valgrind/vgskin_memcheck.so
> Reading symbols from /usr/local/lib/valgrind/valgrind.so...done.
> Loaded symbols for /usr/local/lib/valgrind/valgrind.so
> Reading symbols from /opt/OpenOffice.org644/program/libvcl644li.so...done.
> Loaded symbols for /opt/OpenOffice.org644/program/libvcl644li.so
> ... etc etc ...
> Reading symbols from /opt/OpenOffice.org644/program/libsal.so.3...done.
> Loaded symbols for /opt/OpenOffice.org644/program/libsal.so.3
> Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
> Loaded symbols for /usr/X11R6/lib/libXext.so.6
>
> [1]+  Stopped                 ./soffice-valgrind.sh
>
> If I then do a fg, it seems to continue, but things are all screwed up.
> gdb goes away as soon as it finishes loading up:
>
> vg_do_syscall3 (syscallno=4294966784, arg1=18738, arg2=0, arg3=0)
>      at vg_mylibc.c:92
> 92      }
> (gdb) ==18736==
> ==18736== GDB has detached.  Valgrind regains control.  We continue.
>
> and the app continues on, seemingly in the background, while I'm
> dumped back to the shell.  Very odd.
>
> Any suggestions?
>
> Thanks,
> Dan

[Valgrind-users] openoffice and valgrind1.9.6 - strange problems. Using rh8.

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

Hi, I'm using valgrind 1.9.6 on redhat 8.0 with OpenOffice.
It seems to work fine with no options, but if I turn on
--gdb-attach=yes, I don't get what I expect.  On the
first error, it asks me nicely if I want to run gdb,
and it does start gdb, but here's what I see:

==18736== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y
==18736== starting GDB with cmd: /usr/bin/gdb -nw /proc/18736/exe 18736
GNU gdb Red Hat Linux (5.2.1-4)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(no debugging symbols found)...
Attaching to program: /opt/OpenOffice.org644/program/soffice.bin, process 18736
Reading symbols from /usr/local/lib/valgrind/vgskin_memcheck.so...done.
Loaded symbols for /usr/local/lib/valgrind/vgskin_memcheck.so
Reading symbols from /usr/local/lib/valgrind/valgrind.so...done.
Loaded symbols for /usr/local/lib/valgrind/valgrind.so
Reading symbols from /opt/OpenOffice.org644/program/libvcl644li.so...done.
Loaded symbols for /opt/OpenOffice.org644/program/libvcl644li.so
... etc etc ...
Reading symbols from /opt/OpenOffice.org644/program/libsal.so.3...done.
Loaded symbols for /opt/OpenOffice.org644/program/libsal.so.3
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.6

[1]+  Stopped                 ./soffice-valgrind.sh

If I then do a fg, it seems to continue, but things are all screwed up.
gdb goes away as soon as it finishes loading up:

vg_do_syscall3 (syscallno=4294966784, arg1=18738, arg2=0, arg3=0)
     at vg_mylibc.c:92
92      }
(gdb) ==18736==
==18736== GDB has detached.  Valgrind regains control.  We continue.

and the app continues on, seemingly in the background, while I'm
dumped back to the shell.  Very odd.

Any suggestions?

Thanks,
Dan

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

[Valgrind-users] Patch to make debugging curses programs easier

[Sami L. <sl...@cc...>]

I found the following simple changes helpful in using Valgrind to
debug curses programs with --gdb-attach=yes.

I'd be happy to know if someone has found an easier way to use
--gdb-attach=yes with curses programs; if not, this patch might be
useful for others too.  With it it's possible to read the Y/N for the
"attach gdb" question from any file descriptor (--input=fd=<n>).  The
--gdb-command=<command> option allows e.g. using a script to start gdb
in an xterm (or using openvt).

Attached patch against 1.9.6.

	Sami


diff -ur valgrind-1.9.6/coregrind/vg_errcontext.c valgrind-1.9.6-cursespatch/coregrind/vg_errcontext.c
--- valgrind-1.9.6/coregrind/vg_errcontext.c	2003-01-28 21:59:35.000000000 +0200
+++ valgrind-1.9.6-cursespatch/coregrind/vg_errcontext.c	2003-05-10 18:46:47.000000000 +0300
@@ -141,14 +141,14 @@
       VG_(getpid)()
    );
 
-   res = VG_(read)(0 /*stdin*/, &ch, 1);
+   res = VG_(read)(VG_(clo_input_fd), &ch, 1);
    if (res != 1) goto ioerror;
    /* res == 1 */
    if (ch == '\n') return False;
    if (ch != 'N' && ch != 'n' && ch != 'Y' && ch != 'y' 
       && ch != 'C' && ch != 'c') goto again;
 
-   res = VG_(read)(0 /*stdin*/, &ch2, 1);
+   res = VG_(read)(VG_(clo_input_fd), &ch2, 1);
    if (res != 1) goto ioerror;
    if (ch2 != '\n') goto again;
 
diff -ur valgrind-1.9.6/coregrind/vg_include.h valgrind-1.9.6-cursespatch/coregrind/vg_include.h
--- valgrind-1.9.6/coregrind/vg_include.h	2003-05-05 02:34:22.000000000 +0300
+++ valgrind-1.9.6-cursespatch/coregrind/vg_include.h	2003-05-10 17:57:12.000000000 +0300
@@ -171,6 +171,8 @@
 extern Bool  VG_(clo_error_limit);
 /* Enquire about whether to attach to GDB at errors?   default: NO */
 extern Bool  VG_(clo_GDB_attach);
+/* The command to run as GDB?  default: gdb */
+extern Char* VG_(clo_GDB_command);
 /* Sanity-check level: 0 = none, 1 (default), > 1 = expensive. */
 extern Int   VG_(sanity_level);
 /* Automatically attempt to demangle C++ names?  default: YES */
@@ -205,6 +207,8 @@
 extern Int     VG_(clo_logfile_fd);
 extern Char*   VG_(clo_logfile_name);
 
+/* The file descriptor to read for input. */
+extern Int   VG_(clo_input_fd);
 /* The number of suppression files specified. */
 extern Int   VG_(clo_n_suppressions);
 /* The names of the suppression files. */
diff -ur valgrind-1.9.6/coregrind/vg_main.c valgrind-1.9.6-cursespatch/coregrind/vg_main.c
--- valgrind-1.9.6/coregrind/vg_main.c	2003-05-05 03:03:40.000000000 +0300
+++ valgrind-1.9.6-cursespatch/coregrind/vg_main.c	2003-05-10 18:47:35.000000000 +0300
@@ -457,6 +457,7 @@
 /* Define, and set defaults. */
 Bool   VG_(clo_error_limit)    = True;
 Bool   VG_(clo_GDB_attach)     = False;
+Char*  VG_(clo_GDB_command)    = "gdb";
 Int    VG_(sanity_level)       = 1;
 Int    VG_(clo_verbosity)      = 1;
 Bool   VG_(clo_demangle)       = True;
@@ -469,6 +470,7 @@
 Int     VG_(clo_logfile_fd)    = 2;
 Char*   VG_(clo_logfile_name)  = NULL;
 
+Int    VG_(clo_input_fd)       = 0; /* stdin */
 Int    VG_(clo_n_suppressions) = 0;
 Char*  VG_(clo_suppressions)[VG_CLO_MAX_SFILES];
 Bool   VG_(clo_profile)        = False;
@@ -558,6 +560,7 @@
 "    -q --quiet                run silently; only print error msgs\n"
 "    -v --verbose              be more verbose, incl counts of errors\n"
 "    --gdb-attach=no|yes       start GDB when errors detected? [no]\n"
+"    --gdb-command=<command>   command to run as gdb [gdb]\n"
 "    --demangle=no|yes         automatically demangle C++ names? [yes]\n"
 "    --num-callers=<number>    show <num> callers in stack traces [4]\n"
 "    --error-limit=no|yes      stop showing new errors if too many? [yes]\n"
@@ -567,6 +570,7 @@
 "    --run-libc-freeres=no|yes Free up glibc memory at exit? [yes]\n"
 "    --logfile-fd=<number>     file descriptor for messages [2=stderr]\n"
 "    --logfile=<file>          log messages to <file>.pid<pid>\n"
+"    --input-fd=<number>       file descriptor for input [0=stdin]\n"
 "    --logsocket=ipaddr:port   log messages to socket ipaddr:port\n"
 "    --suppressions=<filename> suppress errors described in\n"
 "                              suppressions file <filename>\n"
@@ -859,6 +863,9 @@
       else if (STREQ(argv[i], "--gdb-attach=no"))
          VG_(clo_GDB_attach) = False;
 
+      else if (STREQN(14,argv[i], "--gdb-command="))
+         VG_(clo_GDB_command) = &argv[i][14];
+
       else if (STREQ(argv[i], "--demangle=yes"))
          VG_(clo_demangle) = True;
       else if (STREQ(argv[i], "--demangle=no"))
@@ -896,6 +903,9 @@
          VG_(clo_logfile_name) = &argv[i][10];
       }
 
+      else if (STREQN(11, argv[i], "--input-fd="))
+         VG_(clo_input_fd)     = (Int)VG_(atoll)(&argv[i][11]);
+
       else if (STREQN(12, argv[i], "--logsocket=")) {
          VG_(clo_log_to)       = VgLogTo_Socket;
          VG_(clo_logfile_name) = &argv[i][12];
@@ -1673,7 +1683,8 @@
    Int   res;
    UChar buf[100];
    VG_(sprintf)(buf,
-                "/usr/bin/gdb -nw /proc/%d/exe %d", 
+                "%s -nw /proc/%d/exe %d",
+                VG_(clo_GDB_command),
                 VG_(getpid)(), VG_(getpid)());
    VG_(message)(Vg_UserMsg, "starting GDB with cmd: %s", buf);
    res = VG_(system)(buf);

RE: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

[Troels W. H. <tr...@th...>]

Hi Julian,

I can confirm that your patch solved my testcase. I tested Valgrind
1.9.6 + patch (applied with a small offset) on RH9.

However... I managed to recreate the exact same problem with another
testcase. The new testcase contains the same code, but runs in a
different thread. Script is attached.

$ python dbboguserrno2.py
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.2/threading.py", line 408, in __bootstrap
    self.run()
  File "dbboguserrno2.py", line 8, in run
    filetype = db.DB_BTREE)
  File "/usr/lib/python2.2/site-packages/rpmdb/dbshelve.py", line 69, in
open
    d.open(filename, dbname, filetype, flags, mode)
DBNoSuchFileError: (2, 'No such file or directory')


$ valgrind python dbboguserrno2.py
==24099== Memcheck, a.k.a. Valgrind, a memory error detector for
x86-linux.
==24099== Copyright (C) 2002, and GNU GPL'd, by Julian Seward.
==24099== Using valgrind-1.9.6, a program instrumentation system for
x86-linux.
==24099== Copyright (C) 2000-2002, and GNU GPL'd, by Julian Seward.
==24099== Estimated CPU clock rate is 436 MHz
==24099== For more details, rerun with: -v
==24099==
==24099== valgrind's libpthread.so: IGNORED call to:
pthread_attr_destroy
Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib/python2.2/threading.py", line 408, in __bootstrap
    self.run()
  File "dbboguserrno2.py", line 8, in run
    filetype = db.DB_BTREE)
  File "/usr/lib/python2.2/site-packages/rpmdb/dbshelve.py", line 69, in
open
    d.open(filename, dbname, filetype, flags, mode)
DBAgainError: (11, 'Resource temporarily unavailable')

Troels

-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Julian
Seward
Sent: 10. mai 2003 02:03
To: Troels Walsted Hansen; val...@li...
Subject: Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind



Thanks for chasing this down.  The attached patch fixes it for me on
R H 9 and SuSE 8.2.  Perhaps you can try it?

J


On Wednesday 07 May 2003 10:01 am, Troels Walsted Hansen wrote:
> Sorry, I managed to forget to attach the script.
>
> Here's the script, as well as two straces, created with the below
> commands, on a RH8+glibc 2.3.3 machine.
>
> strace python dbboguserrno.py 2> strace-normal.txt
> strace valgrind python dbboguserrno.py 2> strace-valgrind.txt
>
> Both traces show the below syscall, but the instance running in
Valgrind
> seems to get EAGAIN instead...
>
> open("nosuchfile.db", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
>
> Troels

Re: [Valgrind-users] Enable SO_REUSEADDR in valgrind-listener

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

Ah, that's great.  Thanks.  I had wondered about how to fix that problem.

J

On Saturday 10 May 2003 9:57 am, Troels Walsted Hansen wrote:
> Restarting valgrind-listener quickly can produce the error below.
> Attached patch fixes it by enabling SO_REUSEADDR for the listening
> socket.
>
> $ valgrind-listener
> valgrind-listener started at Sat May 10 10:39:43 2003
> cannot bind port : Address already in use
>
> valgrind-listener: the `impossible' happened:
>    main -- bind port
> Please report this bug to: js...@ac...

[Valgrind-users] Enable SO_REUSEADDR in valgrind-listener

[Troels W. H. <tr...@th...>]

Restarting valgrind-listener quickly can produce the error below.
Attached patch fixes it by enabling SO_REUSEADDR for the listening
socket.

$ valgrind-listener
valgrind-listener started at Sat May 10 10:39:43 2003
cannot bind port : Address already in use

valgrind-listener: the `impossible' happened:
   main -- bind port
Please report this bug to: js...@ac...

-- 
Troels

Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

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

Thanks for chasing this down.  The attached patch fixes it for me on
R H 9 and SuSE 8.2.  Perhaps you can try it?

J


On Wednesday 07 May 2003 10:01 am, Troels Walsted Hansen wrote:
> Sorry, I managed to forget to attach the script.
>
> Here's the script, as well as two straces, created with the below
> commands, on a RH8+glibc 2.3.3 machine.
>
> strace python dbboguserrno.py 2> strace-normal.txt
> strace valgrind python dbboguserrno.py 2> strace-valgrind.txt
>
> Both traces show the below syscall, but the instance running in Valgrind
> seems to get EAGAIN instead...
>
> open("nosuchfile.db", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
>
> Troels
>
> > -----Original Message-----
> > From: Nicholas Nethercote [mailto:nj...@he...] On
> > Behalf Of Nicholas Nethercote
> > Sent: 7. mai 2003 10:43
> > To: Troels Walsted Hansen
> > Cc: val...@li...
> > Subject: Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind
> >
> > On Wed, 7 May 2003, Troels Walsted Hansen wrote:
> > > This is the expected behavior of the program.
> > >
> > > rpmdb._rpmdb.DBNoSuchFileError: (2, 'No such file or directory')
> > >
> > > This is what happens in Valgrind. RH8 and RH9 uses
> >
> > BerkeleyDB 4.0.14,
> >
> > > rpmdb._rpmdb.DBAgainError: (11, 'Resource temporarily unavailable --
> > > nosuchfile.db: Resource temporarily unavailable')
> >
> > It's possible that Valgrind's doing something slightly
> > different with file
> > handling that means you get a different behaviour.  Do you have more
> > information about what exactly is happening to prompt this
> > error?  Eg. is
> > it trying to open a file with the open() system call, or
> > something like
> > that?  It's very difficult to know what the problem is from your
> > description so far.
> >
> > N

[Valgrind-users] NVidia Suppressions file

[Mathieu M. <Mat...@cr...>]

Hi all,
	For those of you that are using nvidia driver here is my nvidia.supp 
file. I have just discovered that there was a new nvidia driver out 
there. I hope I'll just need to 'sed' from one version to the other.

HTH
mathieu
Ps: my nvidia name are dummy, but this is closed source software! You 
won't be able to do anything even if you will.

#-------- For nvidia-1.0-4349
{
    nvidia1
    Memcheck:Cond
    fun:__nvsym16906
}
{
    nvidia2
    Memcheck:Cond
    obj:/usr/lib/libGLcore.so.1.0.4349
}
{
    nvidia3
    Memcheck:Cond
    fun:NvRmAlloc
}
{
    nvidia4
    Memcheck:Cond
    fun:strcat
    fun:__nvsym17797
}
{
    nvidia5
    Memcheck:Param
    modify_ldt(ptr)(func=1 or 0x11)
    obj:/usr/lib/libGL.so.1.0.4349
}
{
    nvidia6
    Memcheck:Value4
    obj:/usr/lib/libGLcore.so.1.0.4349
}
{
    nvidia-leak1
    Memcheck:Leak
    fun:malloc
    fun:__nvsym17642
}
{
    nvidia-leak2
    Memcheck:Leak
    fun:malloc
    obj:/usr/lib/libGL.so.1.0.4349
}
{
    nvidia-leak3
    Memcheck:Leak
    fun:malloc
    fun:XextAddDisplay
    fun:__nvsym17642
}
# 0x413ACB6C: __nvsym17758 (in /usr/lib/libGL.so.1.0.4349)
{
    nvidia-leak4
    Memcheck:Leak
    fun:calloc
    fun:_dlerror_run
    fun:dlopen@@GLIBC_2.1
}
# 0x413ACF46: __nvsym17729 (in /usr/lib/libGL.so.1.0.4349)
{
    nvidia-leak5
    Memcheck:Leak
    fun:calloc
    fun:__nvsym17729
}

Re: [Valgrind-users] Suppressions...

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

On Fri, 9 May 2003 Joh...@al... wrote:

> Is there any documentation on the usage of suppressions, ie: adding your
> own? The manual just skips over it, and the example docs in the provided
> suppression files are cryptic to say the least. Google turned up
> nothing. I got the old write(buf) one to work, but others seem to be
> just ignored.

The manual is weak on suppressions.  One important thing: C++ function
names must be _mangled_;  use --demangle=no to get mangled names in error
messages.

Or, to make life much easier, check out the CVS HEAD from the
Valgrind SourceForge page, build it (see README for instructions), and use
the --gen-suppressions option to automatically generate suppressions for
you.  This will answer many of your questions, or remove the need for
answers.


> Is Memcheck simply a leak check, and Addrcheck an address validation
> function? Can you suppression uninitialised variables with either of these?

Memcheck checks the validity (definedness) and addressibility of all
memory reads.  Addrcheck only does addressibility checking.  Both do leak
checking (with --leak-check=yes).  Only Memcheck gives errors for
uninitialised variables, and yes you can suppress them.

> What does supp_kind mean, ie: Param vs Free vs Cond

Means "what kind of error is it"?


> are the fun: / obj: sequential, ie:
>
>     fun:_dl_relocate_object*
>     obj:*libc-2.2.?.so
>     fun:_dl_catch_error*
>
> Does that mean its _dl_relocate_object, which is called by anything in
> libc-2.2 and then called by _dl_catch_error.

Yes, except the '*' is a wildcard.  The lines reflect the stack trace in
the error.

> Oh yeah, is the order from bottom to top, ie: is the last function
> first, rather than other way around (I know its the former, but its nice
> to get it stated in documentation...)

First function is the most recently called, ie. the one the error occurred
in.

> Whats core: mean?

The bit before the ':' on the second line indicates what 'skin' (eg.
Memcheck, Addrcheck, etc) the suppression is for;  Valgrind's "core" can
detect some errors itself too, in which case you use "core:".

> {
>     pthread_error/__pthread_mutex_destroy/_IO_default_finish
>     core:PThread
>     fun:pthread_error
>     fun:__pthread_mutex_destroy
>     fun:_IO_default_finish*
> }
>
> The qualifiers, sometimes we get Memcheck:Value4? Addr4? An explanation
> would be nice.
>
> Any pointers to information such as this would be great.

The manual will be improved eventually.  Meanwhile, get the CVS HEAD
version and use --gen-suppressions, it will make your life much easier.

N

[Valgrind-users] Suppressions...

[<Joh...@al...>]

Is there any documentation on the usage of suppressions, ie: adding your 
own? The manual just skips over it, and the example docs in the provided 
suppression files are cryptic to say the least. Google turned up 
nothing. I got the old write(buf) one to work, but others seem to be 
just ignored.

Typical things which would be nice to know:

Memcheck vs Addrcheck:

Is Memcheck simply a leak check, and Addrcheck an address validation 
function? Can you suppression uninitialised variables with either of these?

What does supp_kind mean, ie: Param vs Free vs Cond

What is the qualification for these, ie: using of the optional pars?

are the fun: / obj: sequential, ie:

    fun:_dl_relocate_object*
    obj:*libc-2.2.?.so
    fun:_dl_catch_error*

Does that mean its _dl_relocate_object, which is called by anything in 
libc-2.2 and then called by _dl_catch_error.

Oh yeah, is the order from bottom to top, ie: is the last function 
first, rather than other way around (I know its the former, but its nice 
to get it stated in documentation...)

Whats core: mean?

{
    pthread_error/__pthread_mutex_destroy/_IO_default_finish
    core:PThread
    fun:pthread_error
    fun:__pthread_mutex_destroy
    fun:_IO_default_finish*
}

The qualifiers, sometimes we get Memcheck:Value4? Addr4? An explanation 
would be nice.

Any pointers to information such as this would be great.

Great project though.

    Thanks

      John

[Valgrind-users] Patch to fix suppression-file parser

[Jeffrey S. <fe...@xi...>]

If the number of callers specified in the suppression rule is >=
VG_N_SUPP_CALLERS, the parser gets confused.

The attached patch fixes this condition.

Jeff

-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fe...@xi...  - www.ximian.com

RE: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

[Troels W. H. <tr...@th...>]

Thanks. Let me know if you want me to test any changes.

Troels

-----Original Message-----
From: val...@li...
[mailto:val...@li...] On Behalf Of Julian
Seward
Sent: 8. mai 2003 10:04
To: Troels Walsted Hansen; val...@li...
Subject: Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind



I imagine this is similar to other problems I fixed ... there is two
implementations of errno, in effect, and threaded one and a non-threaded
one and they are getting mixed up.  I'll look into it.  Thx.

J

Re: [Valgrind-users] Probably OT: Losing memory within gethostbyname_r, inet_ntoa

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

On Thu, 8 May 2003, Andreas Oesterhelt wrote:

> The other case is about inet_ntoa, which is supposed to reuse the same
> statically allocated buffer in subsequent requests. Yet I get multiple
> reports like this one:
>
> ==23379== 200 bytes in 1 blocks are still reachable in loss record 9 of 12
> ==23379==    at 0x40244FF4: my_malloc (vg_libpthread.c:267)
> ==23379==    by 0x40246B41: get_or_allocate_specifics_ptr (vg_libpthread.c:1392)
> ==23379==    by 0x40246C56: __pthread_key_create (vg_libpthread.c:1429)
> ==23379==    by 0x40342DF1: init (in /lib/libc.so.6)
> ==23379==    by 0x40246E7C: __pthread_once (vg_libpthread.c:1514)
> ==23379==    by 0x40342D18: inet_ntoa (in /lib/libc.so.6)
> ==23379==    by 0x805F812: accept_connection (jbsockets.c:714)
> ==23379==    by 0x806204D: listen_loop (jcc.c:2252)
> ==23379==    by 0x8061D27: main (jcc.c:2072)
> ==23379==    by 0x402797ED: __libc_start_main (in /lib/libc.so.6)
> ==23379==    by 0x80496F0: (within /home/oes/projekte/privoxy/current/privoxy)
>
> How and why does __pthread_once get called from within inet_ntoa and what
> does valgrind's vg_libpthread need 200 bytes for?

I don't know why __pthread_once is being called, but its' a leak in
Valgrind's libpthread.so;  mmm, embarassing :(   I committed a suppression
for it in the CVS HEAD this morning (it was very hard to track down so we
settled with suppressing it).

N

Re: [Valgrind-users] Probably OT: Losing memory within gethostbyname_r, inet_ntoa

[Crispin F. <cr...@th...>]

Hi,

> The other case is about inet_ntoa, which is supposed to reuse the same
> statically allocated buffer in subsequent requests. Yet I get multiple
> reports like this one:
> 
> ==23379== 200 bytes in 1 blocks are still reachable in loss record 9 of 12
> ==23379==    at 0x40244FF4: my_malloc (vg_libpthread.c:267)
> ==23379==    by 0x40246B41: get_or_allocate_specifics_ptr (vg_libpthread.c:1392)
> ==23379==    by 0x40246C56: __pthread_key_create (vg_libpthread.c:1429)
> ==23379==    by 0x40342DF1: init (in /lib/libc.so.6)
> ==23379==    by 0x40246E7C: __pthread_once (vg_libpthread.c:1514)
> ==23379==    by 0x40342D18: inet_ntoa (in /lib/libc.so.6)
> ==23379==    by 0x805F812: accept_connection (jbsockets.c:714)
> ==23379==    by 0x806204D: listen_loop (jcc.c:2252)
> ==23379==    by 0x8061D27: main (jcc.c:2072)
> ==23379==    by 0x402797ED: __libc_start_main (in /lib/libc.so.6)
> ==23379==    by 0x80496F0: (within /home/oes/projekte/privoxy/current/privoxy)
> 
> How and why does __pthread_once get called from within inet_ntoa and what
> does valgrind's vg_libpthread need 200 bytes for?

The code inside inet_ntoa uses the pthread_once function to initialise
its a pthread key, which allows it to store per-thread data. Valgrind
uses the 200 bytes to store the entries for each of the allocated
pthread keys for each thread. I wouldn't worry about this error at all,
from my reading, the worst you are likely to get is 200 bytes per
thread.

Crispin

[Valgrind-users] Probably OT: Losing memory within gethostbyname_r, inet_ntoa

[Andreas O. <oe...@oe...>]

Hello,

sorry if this is a FAQ or just plain stupid, but I didn't find anything
helpful in the docs, FAQ, nor ML/news archives.

While checking my application for memory leaks, I noticed lots of
reports about allocations made from within glibc library calls,
which seem to contradict the documented behaviour of these functions.

For example, gethostbyname_r is not supposed to do any allocations
at all (the result structure and scratch buffer are provided by
the caller). Yet at exit I get lots of these:

==23379== 416 bytes in 3 blocks are still reachable in loss record 10 of 12
==23379==    at 0x40168A63: calloc (vg_clientfuncs.c:245)
==23379==    by 0x4000CAAC: _dl_check_map_versions (in /lib/ld-2.2.4.so)
==23379==    by 0x4035BEAD: dl_open_worker (in /lib/libc.so.6)
==23379==    by 0x4000B59F: _dl_catch_error (in /lib/ld-2.2.4.so)
==23379==    by 0x4035C0AD: _dl_open (in /lib/libc.so.6)
==23379==    by 0x4035CD44: do_dlopen (in /lib/libc.so.6)
==23379==    by 0x4000B59F: _dl_catch_error (in /lib/ld-2.2.4.so)
==23379==    by 0x4035CCDF: dlerror_run (in /lib/libc.so.6)
==23379==    by 0x4035CDE9: __libc_dlopen (in /lib/libc.so.6)
==23379==    by 0x40340AE3: __nss_lookup_function (in /lib/libc.so.6)
==23379==    by 0x40340670: __nss_next (in /lib/libc.so.6)
==23379==    by 0x40343BD3: gethostbyname_r@@GLIBC_2.1.2 (in /lib/libc.so.6)
==23379==    by 0x805F96F: resolve_hostname_to_ip (jbsockets.c:800)
==23379==    by 0x805F269: connect_to (jbsockets.c:296)
==23379==    by 0x805ED73: forwarded_connect (gateway.c:227)
==23379==    by 0x80604C9: chat (jcc.c:1171)
==23379==    by 0x8061491: serve (jcc.c:1692)
==23379==    by 0x4024582B: thread_wrapper (vg_libpthread.c:671)
==23379==    by 0x4016E9DF: (within /usr/local/lib/valgrind/valgrind.so)

Looking closer it seems as if ld was callocing memory for whatever
use, leaving me with a dynamic allocation that I don't have a pointer
to to free it. Even stranger: This being listed under "still reachable"
implies that there is a pointer -- but where?

Also note the oddness of gethostbyname_r@@GLIBC_2.1.2 although the
application and valgrind were compiled and run on a glibc 2.2.4 system.

The other case is about inet_ntoa, which is supposed to reuse the same
statically allocated buffer in subsequent requests. Yet I get multiple
reports like this one:

==23379== 200 bytes in 1 blocks are still reachable in loss record 9 of 12
==23379==    at 0x40244FF4: my_malloc (vg_libpthread.c:267)
==23379==    by 0x40246B41: get_or_allocate_specifics_ptr (vg_libpthread.c:1392)
==23379==    by 0x40246C56: __pthread_key_create (vg_libpthread.c:1429)
==23379==    by 0x40342DF1: init (in /lib/libc.so.6)
==23379==    by 0x40246E7C: __pthread_once (vg_libpthread.c:1514)
==23379==    by 0x40342D18: inet_ntoa (in /lib/libc.so.6)
==23379==    by 0x805F812: accept_connection (jbsockets.c:714)
==23379==    by 0x806204D: listen_loop (jcc.c:2252)
==23379==    by 0x8061D27: main (jcc.c:2072)
==23379==    by 0x402797ED: __libc_start_main (in /lib/libc.so.6)
==23379==    by 0x80496F0: (within /home/oes/projekte/privoxy/current/privoxy)

How and why does __pthread_once get called from within inet_ntoa and what
does valgrind's vg_libpthread need 200 bytes for?

Any hints are greatly appreciated.

Thanks,
--Andreas

Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

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

I imagine this is similar to other problems I fixed ... there is two
implementations of errno, in effect, and threaded one and a non-threaded
one and they are getting mixed up.  I'll look into it.  Thx.

J


On Wednesday 07 May 2003 10:01 am, Troels Walsted Hansen wrote:
> Sorry, I managed to forget to attach the script.
>
> Here's the script, as well as two straces, created with the below
> commands, on a RH8+glibc 2.3.3 machine.
>
> strace python dbboguserrno.py 2> strace-normal.txt
> strace valgrind python dbboguserrno.py 2> strace-valgrind.txt
>
> Both traces show the below syscall, but the instance running in Valgrind
> seems to get EAGAIN instead...
>
> open("nosuchfile.db", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = -1 ENOENT (No
> such file or directory)
>
> Troels
>
> > -----Original Message-----
> > From: Nicholas Nethercote [mailto:nj...@he...] On
> > Behalf Of Nicholas Nethercote
> > Sent: 7. mai 2003 10:43
> > To: Troels Walsted Hansen
> > Cc: val...@li...
> > Subject: Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind
> >
> > On Wed, 7 May 2003, Troels Walsted Hansen wrote:
> > > This is the expected behavior of the program.
> > >
> > > rpmdb._rpmdb.DBNoSuchFileError: (2, 'No such file or directory')
> > >
> > > This is what happens in Valgrind. RH8 and RH9 uses
> >
> > BerkeleyDB 4.0.14,
> >
> > > rpmdb._rpmdb.DBAgainError: (11, 'Resource temporarily unavailable --
> > > nosuchfile.db: Resource temporarily unavailable')
> >
> > It's possible that Valgrind's doing something slightly
> > different with file
> > handling that means you get a different behaviour.  Do you have more
> > information about what exactly is happening to prompt this
> > error?  Eg. is
> > it trying to open a file with the open() system call, or
> > something like
> > that?  It's very difficult to know what the problem is from your
> > description so far.
> >
> > N

Re: [Valgrind-users] New file descriptor leak detection patch (bug fix)

[Robert W. <rj...@du...>]

> =3D=3D12597=3D=3D    Attempting to close unopened file descriptor 13
> =3D=3D12597=3D=3D    Attempting to close unopened file descriptor 14
> =3D=3D12597=3D=3D    Attempting to close unopened file descriptor 15
> =3D=3D12597=3D=3D    Attempting to close unopened file descriptor 16
> =3D=3D12597=3D=3D    Attempting to close unopened file descriptor 17
> =3D=3D12597=3D=3D    Attempting to close unopened file descriptor 18
> etc.
>=20
>=20
> It would be nice to make this message only get printed once (also I
> think that this may make the supressions stuff work for these stack
> traces).

I've a new version coming along any day now that has a number of
improvements, including removing these messages altogether.  They're an
annoyance and not that useful.  The new version also supports a number
of bits and pieces that I missed the last time (F_DUPFD, creat, etc.)
and also tries to figure out more information on sockets to make
debugging easier.

Regards,
 Robert.

--=20
Robert Walsh
Amalgamated Durables, Inc.  -  "We don't make the things you buy."
Email: rj...@du...

Re: [Valgrind-users] Valgrind newb here needs help ;-)

[Tristan V. B. <va...@to...>]

David Eriksson wrote:
> 
> (It is not advisable to start a new topic by replying to an old mail.
> Many mail agents threads messages so that this mail thread shows inside
> of the "BerkeleyDB gets bogus errno in Valgrind" thread.)

True, true. whats done is done, might as well stick to 
the bogus errno thread as opposed to starting a new thread
with `Re:...'.

I changed here:
> > #ifdef GLIBC_2_1
> > int msgsnd(int msgid,       void *msgp, size_t msgsz, int msgflg)
> > #else
> > int msgsnd(int msgid, const void *msgp, size_t msgsz, int msgflg)
> > #endif
for:
> > #ifndef GLIBC_2_1
> > int msgsnd(int msgid,       void *msgp, size_t msgsz, int msgflg)
> > #else
> > int msgsnd(int msgid, const void *msgp, size_t msgsz, int msgflg)
> > #endif

seeing as editing the config.h induced vomiting:

vg_scheduler.c: In function `do_pthread_mutex_lock':
vg_scheduler.c:2406: `PTHREAD_MUTEX_TIMED_NP' undeclared (first use in
this function)
vg_scheduler.c:2406: (Each undeclared identifier is reported only once
vg_scheduler.c:2406: for each function it appears in.)
vg_scheduler.c:2407: `PTHREAD_MUTEX_ADAPTIVE_NP' undeclared (first use
in this function)
vg_scheduler.c: In function `do_pthread_mutex_unlock':
vg_scheduler.c:2519: `PTHREAD_MUTEX_TIMED_NP' undeclared (first use in
this function)
vg_scheduler.c:2520: `PTHREAD_MUTEX_ADAPTIVE_NP' undeclared (first use
in this function)
vg_scheduler.c: In function `do_pthread_cond_wait':
vg_scheduler.c:2761: `PTHREAD_MUTEX_TIMED_NP' undeclared (first use in
this function)
vg_scheduler.c:2762: `PTHREAD_MUTEX_ADAPTIVE_NP' undeclared (first use
in this functio

Now everything compiles sweetly ;-)

Thanks for your support,
			-Tristan



-- 
Education is imposed ignorance. -- Noam Chomsky

Re: [Valgrind-users] Valgrind newb here needs help ;-)

[David E. <da...@2g...>]

(It is not advisable to start a new topic by replying to an old mail.
Many mail agents threads messages so that this mail thread shows inside
of the "BerkeleyDB gets bogus errno in Valgrind" thread.)

On Wed, 2003-05-07 at 19:26, Tristan Van Berkom wrote:
> Hi everyone!
> 	I develop jukebox apliences under linux and am considering
> valgrind as a memory debugging tool. Personaly I do not have a vast
> knowlage
> on cpu's and all that jazz, acronymes et al so please bear with me.
> 
> 
> My questions are the following:
> 
>     Considering that gcc doesn't generate opcodes for anything other
> than i386 if not specified and that valgrind takes the i486 instruction
> set as a baseline:
> 
>         Would it be a fatal mistake to assume that valgrind will support
>     the i386 instruction set as a consiquence of supporting the i486
>     instruction set ((i486 >= i386) ? backwards compatible) ?
> 
>     or would I have to recompile all my code with `-march=i486' ?
> 
> ===================== from `info gcc' (-mcpu=option) ================
>      While picking a specific CPU TYPE will schedule things
>      appropriately for that particular chip, the compiler will not
>      generate any code that does not run on the i386 without the
>      `-march=CPU TYPE' option being used.  `i586' is equivalent to
>      `pentium' and `i686' is equivalent to `pentiumpro'.  `k6' is the
>      AMD chip as opposed to the Intel ones.
> =====================================================================

You don't have to compile your code for i486. Compiling for i386 is just
fine as the i386 instructions is a subset of the i486 instruction set.

>     I'm a real dunce when it comes to automake and friends ;-)
> I ran `./configure --prefix=/usr/local' followed by `make'.
> (after that I tried a slew of options such as --host, --build,
> --target all of which I cant seem to get right even while
> searching through the config.sub).

Just a note: /usr/local is the default prefix. If you want valgrind
installed with this prefix you don't need a single option to valgrind.

> This is the compile command issued by make that failed:
> ======================================================================
> source='vg_intercept.c' object='vg_intercept.o' libtool=no \
> depfile='.deps/vg_intercept.Po' tmpdepfile='.deps/vg_intercept.TPo' \
> depmode=gcc /bin/sh ../depcomp \
> gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include    
> -DVG_LIBDIR="\"/usr/local/lib"\" -Winline -Wall -Wshadow -O
> -fomit-frame-pointer -mpreferred-stack-boundary=2 -g
> -fno-omit-frame-pointer -c `test -f 'vg_intercept.c' || echo
> './'`vg_intercept.c
> 
> This is the error isued:
> =================================================
> vg_intercept.c:419: conflicting types for `msgsnd'
> /usr/include/sys/msg.h:74: previous declaration of `msgsnd'
> 
> and theese are the prototypes:
> ============ vg_intercept.c:419 =================
> #ifdef GLIBC_2_1
> int msgsnd(int msgid,       void *msgp, size_t msgsz, int msgflg)
> #else
> int msgsnd(int msgid, const void *msgp, size_t msgsz, int msgflg)
> #endif
> 
> ============ /usr/include/sys/msg.h ============
> extern int msgsnd __P ((int __msqid, __const void *__msgp, size_t
> __msgsz,
>                         int __msgflg));
> 
> I have to admit that after 3 years of seeing this damn macro in header
> files I still haven't figured out exactly what it does (`__P') but I
> have
> a hunch that it removes some of theese leading underscores.
> 
> What I do find strange is that in my `msg.h' msgp is `const' and 
> that comes from GLIBC_2_1 !!! but if that conditional directive
> was buggy; nobody else would be able to compile valgrind either 
> (I think). (BTW, GLIBC_2_1 is defined in the config.h)
> 
> I am using:
> gcc          2.95.3
> Linux kernel 2.4.16
> glibc        2.1.3-5
> valgrind     1.9.6 (latest)
> (missing anything ?)
> 
> Any help with my compile situation is greatly apreciated.

After running ./configure, remove GLIBC_2_1 from config.h. This solution
is of course a hack, but you should at least be able to compile
valgrind.

-- 
-\- David Eriksson -/-                              www.2GooD.nu
 
"I personally refuse to use inferior tools because of ideology."
                                                - Linus Torvalds

[Valgrind-users] Valgrind newb here needs help ;-)

[Tristan V. B. <va...@to...>]

Hi everyone!
	I develop jukebox apliences under linux and am considering
valgrind as a memory debugging tool. Personaly I do not have a vast
knowlage
on cpu's and all that jazz, acronymes et al so please bear with me.


My questions are the following:

    Considering that gcc doesn't generate opcodes for anything other
than i386 if not specified and that valgrind takes the i486 instruction
set as a baseline:

        Would it be a fatal mistake to assume that valgrind will support
    the i386 instruction set as a consiquence of supporting the i486
    instruction set ((i486 >= i386) ? backwards compatible) ?

    or would I have to recompile all my code with `-march=i486' ?

===================== from `info gcc' (-mcpu=option) ================
     While picking a specific CPU TYPE will schedule things
     appropriately for that particular chip, the compiler will not
     generate any code that does not run on the i386 without the
     `-march=CPU TYPE' option being used.  `i586' is equivalent to
     `pentium' and `i686' is equivalent to `pentiumpro'.  `k6' is the
     AMD chip as opposed to the Intel ones.
=====================================================================

    I'm a real dunce when it comes to automake and friends ;-)
I ran `./configure --prefix=/usr/local' followed by `make'.
(after that I tried a slew of options such as --host, --build,
--target all of which I cant seem to get right even while
searching through the config.sub).

This is the compile command issued by make that failed:
======================================================================
source='vg_intercept.c' object='vg_intercept.o' libtool=no \
depfile='.deps/vg_intercept.Po' tmpdepfile='.deps/vg_intercept.TPo' \
depmode=gcc /bin/sh ../depcomp \
gcc -DHAVE_CONFIG_H -I. -I. -I.. -I./demangle -I../include    
-DVG_LIBDIR="\"/usr/local/lib"\" -Winline -Wall -Wshadow -O
-fomit-frame-pointer -mpreferred-stack-boundary=2 -g
-fno-omit-frame-pointer -c `test -f 'vg_intercept.c' || echo
'./'`vg_intercept.c

This is the error isued:
=================================================
vg_intercept.c:419: conflicting types for `msgsnd'
/usr/include/sys/msg.h:74: previous declaration of `msgsnd'

and theese are the prototypes:
============ vg_intercept.c:419 =================
#ifdef GLIBC_2_1
int msgsnd(int msgid,       void *msgp, size_t msgsz, int msgflg)
#else
int msgsnd(int msgid, const void *msgp, size_t msgsz, int msgflg)
#endif

============ /usr/include/sys/msg.h ============
extern int msgsnd __P ((int __msqid, __const void *__msgp, size_t
__msgsz,
                        int __msgflg));

I have to admit that after 3 years of seeing this damn macro in header
files I still haven't figured out exactly what it does (`__P') but I
have
a hunch that it removes some of theese leading underscores.

What I do find strange is that in my `msg.h' msgp is `const' and 
that comes from GLIBC_2_1 !!! but if that conditional directive
was buggy; nobody else would be able to compile valgrind either 
(I think). (BTW, GLIBC_2_1 is defined in the config.h)

I am using:
gcc          2.95.3
Linux kernel 2.4.16
glibc        2.1.3-5
valgrind     1.9.6 (latest)
(missing anything ?)

Any help with my compile situation is greatly apreciated.


Regards
			-Tristan


-- 
Education is imposed ignorance. -- Noam Chomsky

[Valgrind-users] Patch for valgrind-listener

[Crispin F. <cr...@th...>]

While using the fd leak checking patch by Robert Walsh, I found a fd
leak in valgrind-listener, it never closes any file descriptors. While
looking at the code, I removed the nanosleep() calls so that it just
sits in poll() waiting for a new connection or data on an existing
connection.

The patch is attached.

Crispin

Re: [Valgrind-users] New file descriptor leak detection patch (bug fix)

[Crispin F. <cr...@th...>]

On Tue, 2003-04-22 at 08:43, Robert Walsh wrote:
> Hi all,
> 
> Here's a new version of the file descriptor leakage patch that solves a
> memory error (sigh - this is where being able to valgrind valgrind would
> be handy) in my original implementation.  Feedback welcome.
I have been using this quite a bit recently, and it works pretty well,
however I have a comment:

I have some code that calls close() on the first 512 fd's, and although
the stacktrace is only printed once, the "Attempting to close unopened
file descriptor 13" is printed every time, giving me the following
output:

==12597== Invalid close()
==12597==    at 0x402FE97D: __libc_close (in /lib/libc-2.3.1.so)
==12597==    by 0x8171767: ParentBoot() (parent.cpp:1623)
==12597==    by 0x81AB204: main (z4.cpp:613)
==12597==    by 0x4025CA50: __libc_start_main (in /lib/libc-2.3.1.so)
==12597==    Attempting to close unopened file descriptor 13
==12597==    Attempting to close unopened file descriptor 14
==12597==    Attempting to close unopened file descriptor 15
==12597==    Attempting to close unopened file descriptor 16
==12597==    Attempting to close unopened file descriptor 17
==12597==    Attempting to close unopened file descriptor 18
etc.


It would be nice to make this message only get printed once (also I
think that this may make the supressions stuff work for these stack
traces).

Crispin

RE: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind

[Troels W. H. <tr...@th...>]

Sorry, I managed to forget to attach the script.

Here's the script, as well as two straces, created with the below
commands, on a RH8+glibc 2.3.3 machine.

strace python dbboguserrno.py 2> strace-normal.txt
strace valgrind python dbboguserrno.py 2> strace-valgrind.txt

Both traces show the below syscall, but the instance running in Valgrind
seems to get EAGAIN instead...

open("nosuchfile.db", O_RDONLY|O_NONBLOCK|O_LARGEFILE) = -1 ENOENT (No
such file or directory)

Troels

> -----Original Message-----
> From: Nicholas Nethercote [mailto:nj...@he...] On 
> Behalf Of Nicholas Nethercote
> Sent: 7. mai 2003 10:43
> To: Troels Walsted Hansen
> Cc: val...@li...
> Subject: Re: [Valgrind-users] BerkeleyDB gets bogus errno in Valgrind
> 
> 
> On Wed, 7 May 2003, Troels Walsted Hansen wrote:
> 
> > This is the expected behavior of the program.
> >
> > rpmdb._rpmdb.DBNoSuchFileError: (2, 'No such file or directory')
> >
> > This is what happens in Valgrind. RH8 and RH9 uses 
> BerkeleyDB 4.0.14,
> 
> > rpmdb._rpmdb.DBAgainError: (11, 'Resource temporarily unavailable --
> > nosuchfile.db: Resource temporarily unavailable')
> 
> It's possible that Valgrind's doing something slightly 
> different with file
> handling that means you get a different behaviour.  Do you have more
> information about what exactly is happening to prompt this 
> error?  Eg. is
> it trying to open a file with the open() system call, or 
> something like
> that?  It's very difficult to know what the problem is from your
> description so far.
> 
> N
>