valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] at a loss

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

On Tue, 13 May 2003, Michael Labhard wrote:

> I am at a loss as to how to use valgrind.  I have read the manual and a
> howto.  Using this command
>
> export GLIBCPP_FORCE_NEW=1;
> valgrind
> --skin=memcheck

Memcheck is the default skin, so this flag is unnecessary

> --leak-check=yes
> --show-reachable=yes

Don't use --show-reachable=yes and you won't the the "still reachable in
loss record" messages below;  they're not so important, they show memory
that your program could have freed (it's still reachable via some
pointer) but didn't bother to.

> --logfile=debug.out
> --suppressions=xfree-3.supp
> --suppressions=xfree-4.supp --suppressions=default.supp --suppressions=glibc-2.2.supp

default.supp is used as the default suppression file so you don't need to
specify it.  It's constructed at ./configure time from the relevant
xfree/glibc/linux .supp files, so you don't need to mentiont them either.

> src/.libs/lt-myapp
>
> My application produces hundreds of lines looking like
>
> ==26316== 216 bytes in 21 blocks are still reachable in loss record 77 of 124
> ==26316==    at 0x40160989: malloc (in /usr/lib/valgrind/valgrind.so)
> ==26316==    by 0x40B33B2F: __GI___strdup (in /lib/libc-2.3.1.so)
> ==26316==    by 0x40F5C37A: resolve_object (in /usr/X11R6/lib/libX11.so.6.2)
> ==26316==    by 0x40F5BF7C: _XlcDynamicLoad (in /usr/X11R6/lib/libX11.so.6.2)
> ==26316==
>
> What do I do with this stuff?  It looks like it comes from an X11 library but
> the command line includes suppressions for X11.  Why isn't X11 output
> suppressed?  Where do I get a suppressions file for Qt?

If you look in any of the .supp files, you'll see many suppressions for
individual errors.  These have been added as they were encountered.  They
should cover most X11 errors people get, but we may have missed some, or
your machine might have an unusual configuration that means some errors
are getting through.  You can write your own suppressions;  the manual
currently doesn't explain how to very well, it would be easier to check
out the CVS HEAD (from sourceforge.net) and use the --gen-suppressions
feature to automatically generate suppressions (the feature isn't in
1.9.6).

But first, just try "valgrind --leak-check=yes <program>", see how that
works.

N

[Valgrind-users] at a loss

[Michael L. <in...@pa...>]

I am at a loss as to how to use valgrind.  I have read the manual and a h=
owto. =20
Using this command=20

export GLIBCPP_FORCE_NEW=3D1; valgrind --skin=3Dmemcheck --leak-check=3Dy=
es=20
--show-reachable=3Dyes --logfile=3Ddebug.out --suppressions=3Dxfree-3.sup=
p=20
--suppressions=3Dxfree-4.supp --suppressions=3Ddefault.supp=20
--suppressions=3Dglibc-2.2.supp src/.libs/lt-myapp

My application produces hundreds of lines looking like

=3D=3D26316=3D=3D 216 bytes in 21 blocks are still reachable in loss reco=
rd 77 of 124
=3D=3D26316=3D=3D    at 0x40160989: malloc (in /usr/lib/valgrind/valgrind=
=2Eso)
=3D=3D26316=3D=3D    by 0x40B33B2F: __GI___strdup (in /lib/libc-2.3.1.so)
=3D=3D26316=3D=3D    by 0x40F5C37A: resolve_object (in /usr/X11R6/lib/lib=
X11.so.6.2)
=3D=3D26316=3D=3D    by 0x40F5BF7C: _XlcDynamicLoad (in /usr/X11R6/lib/li=
bX11.so.6.2)
=3D=3D26316=3D=3D=20

What do I do with this stuff?  It looks like it comes from an X11 library=
 but=20
the command line includes suppressions for X11.  Why isn't X11 output=20
suppressed?  Where do I get a suppressions file for Qt?

Thanks.

-- Michael

Re: [Valgrind-users] [Helgrind] Segfault -> mallocSanityCheckArena

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

On Tue, 2003-05-13 at 07:26, Nicholas Nethercote wrote:

> On Tue, 13 May 2003 gt...@ma... wrote:
> 
> > I get the below error when trying to use Helgrind on VTK based applications
> > (www.vtk.org).
> 
> > blockSane: fail -- redzone-hi
> > mallocSanityCheckArena: sb 0x4238A000, block 3007 (bszW 10):  BAD
> 
> Looks like Helgrind has a heap-block overrun (how embarassing).  Thanks
> for the report.

Very.  David, I don't suppose you have a smaller test case to reproduce
this?

    J

[Valgrind-users] [OT] %ebx changing in poll()

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

Hi,

This is slightly off-topic but since I discovered it when hacking Valgrind
it's worth a shot:  I find that when the poll() system call is made,
sometimes the value of %ebx (which holds the 1st argument) changes, being
increased by 8.  A sample call:

  poll ( 0x804A6C0, 0, 0 )

(which returns 0) doesn't change %ebx.  But another call:

  poll ( 0xBFFFF310, 1, 0 )

does.

No other syscall I've seen changes any of its argument (and I've checked
it on some pretty big programs).  I have a patched 2.4.19-3 kernel.

Any ideas?

N

Re: [Valgrind-users] [Helgrind] Segfault -> mallocSanityCheckArena

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

On Tue, 13 May 2003 gt...@ma... wrote:

> I get the below error when trying to use Helgrind on VTK based applications
> (www.vtk.org).

> blockSane: fail -- redzone-hi
> mallocSanityCheckArena: sb 0x4238A000, block 3007 (bszW 10):  BAD

Looks like Helgrind has a heap-block overrun (how embarassing).  Thanks
for the report.

N

[Valgrind-users] [Helgrind] Segfault -> mallocSanityCheckArena

[<gt...@ma...>]

I get the below error when trying to use Helgrind on VTK based applicatio=
ns
(www.vtk.org).  When the sanity-level is at the default, Valgrind seg-fau=
lts
without any warning or other output.  This happens very early in the exec=
ution
of the program.

$ valgrind --skin=3Dhelgrind --sanity-level=3D5 ./ParaView
=3D=3D22474=3D=3D Helgrind, a data race detector for x86-linux.
=3D=3D22474=3D=3D Copyright (C) 2002, and GNU GPL'd, by Nicholas Netherco=
te.
=3D=3D22474=3D=3D Using valgrind-1.9.6, a program instrumentation system =
for x86-linux.
=3D=3D22474=3D=3D Copyright (C) 2000-2002, and GNU GPL'd, by Julian Sewar=
d.
=3D=3D22474=3D=3D Estimated CPU clock rate is 1994 MHz
=3D=3D22474=3D=3D For more details, rerun with: -v
=3D=3D22474=3D=3D
--22474-- mSC [core    ]:  1 sbs,   197 tot bs,    1/1    free bs, 16 lis=
ts,
1048576 mmap,    7324 loan
--22474-- mSC [skin    ]:  1 sbs,    52 tot bs,    1/1    free bs, 16 lis=
ts,
1048576 mmap,    1212 loan
--22474-- mSC [symtab  ]:  0 sbs,     0 tot bs,    0/0    free bs, 16 lis=
ts,  =20
   0 mmap,       0 loan
--22474-- mSC [JITter  ]:  0 sbs,     0 tot bs,    0/0    free bs, 16 lis=
ts,  =20
   0 mmap,       0 loan
--22474-- mSC [client  ]:  0 sbs,     0 tot bs,    0/0    free bs, 16 lis=
ts,  =20
   0 mmap,       0 loan
--22474-- mSC [demangle]:  0 sbs,     0 tot bs,    0/0    free bs, 16 lis=
ts,  =20
   0 mmap,       0 loan
--22474-- mSC [exectxt ]:  0 sbs,     0 tot bs,    0/0    free bs, 16 lis=
ts,  =20
   0 mmap,       0 loan
--22474-- mSC [errors  ]:  0 sbs,     0 tot bs,    0/0    free bs, 16 lis=
ts,  =20
   0 mmap,       0 loan
--22474-- mSC [transien]:  0 sbs,     0 tot bs,    0/0    free bs, 16 lis=
ts,  =20
   0 mmap,       0 loan
blockSane: fail -- redzone-hi
mallocSanityCheckArena: sb 0x4238A000, block 3007 (bszW 10):  BAD

valgrind: the `impossible' happened:
   mallocSanityCheckArena
Basic block ctr is approximately 50000

sched status:

Thread 1: status =3D Runnable, associated_mx =3D 0x0, associated_cv =3D 0=
x0
=3D=3D22474=3D=3D    at 0x4000F85E: strcmp (in /lib/ld-2.2.5.so)
=3D=3D22474=3D=3D    by 0x4000B0A5: fixup (in /lib/ld-2.2.5.so)
=3D=3D22474=3D=3D    by 0x4000B22F: _dl_runtime_resolve (in /lib/ld-2.2.5=
.so)
=3D=3D22474=3D=3D    by 0x41E0BEC8: (within
/extra/paraview/ParaViewComplete06/lib/libvtkexpat.so)


When run using the Memcheck skin, the program runs fine.  The first error
reported (which appears to later in the programs execuation) is:
=3D=3D22494=3D=3D pthread_attr_setscope: invalid or unsupported scope
=3D=3D22494=3D=3D    at 0x40215CFF: pthread_error (vg_libpthread.c:290)
=3D=3D22494=3D=3D    by 0x40215E86: pthread_attr_setscope (vg_libpthread.=
c:410)
=3D=3D22494=3D=3D    by 0x420CF2A5: vtkMultiThreader::SingleMethodExecute=
(void) (in
/extra/paraview/ParaViewCompe06/lib/libvtkCommon.so)
=3D=3D22494=3D=3D    by 0x41F399E5: vtkImageToImageFilter::MultiThread(vt=
kImageData *,
vtkImageData *) (in /extraraview/ParaViewComplete06/lib/libvtkFiltering.s=
o)

Valgrind version 1.9.6 stable release on Red Hat Linux 7.2 (?), kernel 2.=
4.18-3.


David Bauer

Re: [Valgrind-users] ezmlm response

[Olly B. <ol...@su...>]

On Tue, May 13, 2003 at 11:16:47AM -0000, dev...@op... wrote:
> Hi! This is the ezmlm program. I'm managing the
> de...@op... mailing list.
> 
> Acknowledgment: The address
> 
>    val...@li...
> 
> was not on the dev mailing list when I received
> your request and is not a subscriber of this list.

Hmm, I've been getting double posts for the openoffice.org messages, which
from the headers appear to be coming from the de...@op... mailing
list via the valgrind-users list, but the valgrind-users list isn't
subscribed to de...@op....

Did someone else beat me to unsubscribing it?  Or is something more
peculiar happening?  Whatever is going on, it's annoying to get double
posts so it'd be good if it got fixed...

Cheers,
    Olly

[Valgrind-users] ezmlm response

[<dev...@op...>]

Hi! This is the ezmlm program. I'm managing the
de...@op... mailing list.

Acknowledgment: The address

   val...@li...

was not on the dev mailing list when I received
your request and is not a subscriber of this list.

If you unsubscribe, but continue to receive mail, you're subscribed
under a different address than you currently use. Please look at the
header for:

'Return-Path: <dev-return-1234-user=hos...@op...>'

The unsubscribe address for this user would be:
'dev-unsubscribe-user=hos...@op...'.
Just mail to that address, substituting user=host.dom for the real
values, reply to the confirmation request, and you should receive a message
that you're off the list.

For some mail programs, you need to make the headers visible to
see the return path:

For Eudora 4.0, click on the "Blah blah ..." button.
For PMMail, click on "Window->Show entire message/header". 

If this still doesn't work, I'm sorry to say that I can't help you.
Please FORWARD a list message together with a note about what you're
trying to achieve and a list of addresses that you might be subscribed
under to my owner:

    dev...@op...

who will take care of it. My owner is a little bit slower than I am, 
so please be patient.


--- Administrative commands for the dev list ---

I can handle administrative requests automatically. Please
do not send them to the list address! Instead, send
your message to the correct command address:

To subscribe to the list, send a message to:
   <dev...@op...>

To remove your address from the list, send a message to:
   <dev...@op...>

Send mail to the following for info and FAQ for this list:
   <dev...@op...>
   <de...@op...>

Similar addresses exist for the digest list:
   <dev...@op...>
   <dev...@op...>

To get messages 123 through 145 (a maximum of 100 per request), mail:
   <dev...@op...>

To get an index with subject and author for messages 123-456 , mail:
   <dev...@op...>

They are always returned as sets of 100, max 2000 per request,
so you'll actually get 100-499.

To receive all messages with the same subject as message 12345,
send an empty message to:
   <dev...@op...>

The messages do not really need to be empty, but I will ignore
their content. Only the ADDRESS you send to is important.

You can start a subscription for an alternate address,
for example "jo...@ho...main", just add a hyphen and your
address (with '=' instead of '@') after the command word:
<dev-subscribe-john=hos...@op...>

To stop subscription for this address, mail:
<dev-unsubscribe-john=hos...@op...>

In both cases, I'll send a confirmation message to that address. When
you receive it, simply reply to it to complete your subscription.

If despite following these instructions, you do not get the
desired results, please contact my owner at
dev...@op.... Please be patient, my owner is a
lot slower than I am ;-)

--- Enclosed is a copy of the request I received.

Return-Path: <ol...@su...>
Received: (qmail 25829 invoked from network); 13 May 2003 11:16:46 -0000
Received: from ixion.tartarus.org (195.149.39.210)
  by s002.sfo.collab.net with SMTP; 13 May 2003 11:16:46 -0000
Received: from olly by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
	id 19FXm1-0005da-00; Tue, 13 May 2003 12:16:45 +0100
Date: Tue, 13 May 2003 12:16:45 +0100
From: Olly Betts <ol...@su...>
To: dev-uc.1052824302.elkplmkaambcampcbpbm-valgrind-users=lis...@op...
Subject: Re: [Valgrind-users] confirm unsubscribe from de...@op...
Message-ID: <200...@su...>
References: <105...@op...>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <105...@op...>
User-Agent: Mutt/1.3.28i

Thanks.

[Valgrind-users] confirm unsubscribe from dev@openoffice.org

[<dev...@op...>]

Hi! This is the ezmlm program. I'm managing the
de...@op... mailing list.

To confirm that you would like

   val...@li...

removed from the dev mailing list, please send an empty reply 
to this address:

   dev-uc.1052824302.elkplmkaambcampcbpbm-valgrind-users=lis...@op...

Usually, this happens when you just hit the "reply" button.
If this does not work, simply copy the address and paste it into
the "To:" field of a new message.

I haven't checked whether your address is currently on the mailing list.
To see what address you used to subscribe, look at the messages you are
receiving from the mailing list. Each message has your address hidden
inside its return path; for example, ma...@xd... receives messages
with return path: <dev-return-<number>-mary=xdd...@op....

Some mail programs are broken and cannot handle long addresses. If you
cannot reply to this request, instead send a message to
<dev...@op...> and put the entire address listed above
into the "Subject:" line.


--- Administrative commands for the dev list ---

I can handle administrative requests automatically. Please
do not send them to the list address! Instead, send
your message to the correct command address:

To subscribe to the list, send a message to:
   <dev...@op...>

To remove your address from the list, send a message to:
   <dev...@op...>

Send mail to the following for info and FAQ for this list:
   <dev...@op...>
   <de...@op...>

Similar addresses exist for the digest list:
   <dev...@op...>
   <dev...@op...>

To get messages 123 through 145 (a maximum of 100 per request), mail:
   <dev...@op...>

To get an index with subject and author for messages 123-456 , mail:
   <dev...@op...>

They are always returned as sets of 100, max 2000 per request,
so you'll actually get 100-499.

To receive all messages with the same subject as message 12345,
send an empty message to:
   <dev...@op...>

The messages do not really need to be empty, but I will ignore
their content. Only the ADDRESS you send to is important.

You can start a subscription for an alternate address,
for example "jo...@ho...main", just add a hyphen and your
address (with '=' instead of '@') after the command word:
<dev-subscribe-john=hos...@op...>

To stop subscription for this address, mail:
<dev-unsubscribe-john=hos...@op...>

In both cases, I'll send a confirmation message to that address. When
you receive it, simply reply to it to complete your subscription.

If despite following these instructions, you do not get the
desired results, please contact my owner at
dev...@op.... Please be patient, my owner is a
lot slower than I am ;-)

--- Enclosed is a copy of the request I received.

Return-Path: <ol...@su...>
Received: (qmail 23755 invoked from network); 13 May 2003 11:11:42 -0000
Received: from ixion.tartarus.org (195.149.39.210)
  by s002.sfo.collab.net with SMTP; 13 May 2003 11:11:42 -0000
Received: from olly by ixion.tartarus.org with local (Exim 3.35 #1 (Debian))
	id 19FXh7-0004QA-00; Tue, 13 May 2003 12:11:41 +0100
Date: Tue, 13 May 2003 12:11:41 +0100
From: Olly Betts <ol...@su...>
To: dev-unsubscribe-valgrind-users=lis...@op...
Subject: Please unsubscribe the valgrind-users mailing list
Message-ID: <200...@su...>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.28i

Re: [Valgrind-users] Using Valgrind with my Own Memory Management

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

On Mon, 12 May 2003, Seto wrote:

> Has anyone been using Valgrind successfully with his/her
> own memory management or maybe has some ideas on what
> should people do when using Valgrind with their own memory
> management, so Valgrind will report useful memory information?

It will still work, but give less information.  The validity checks will
be fine.  The addressability checks will be less accurate, because your
allocator might allocate superblocks and then dole out small blocks from
within that; so small-block-overruns probably wouldn't be found. Some
other errors you obviously won't get (eg. mismatched malloc/new/new[] vs.
free/delete/delete[], accessing blocks after free()ing them).  Memory leak
checking (--leak-check) also won't be any use as it's based around
recording malloc/new/new[] blocks.  Also, error locations will be less
accurate, as errors within your non-malloc'd blocks won't be identified as
such.

----

Hmm... some client requests could be useful here.  For example:

  VALGRIND_MALLOCLIKE_BLOCK(mallocname, addr, rz1, size, rz2)
  VALGRIND_FREELIKE_BLOCK(freename, addr, rz1, rz2)

The first would tell Valgrind that the block at 'addr' of size 'size' is a
malloc-like block and should be recorded as such, the second should be
obvious.  You could use it like this:

void* my_alloc(int size)
{
    void* p = <get memory block somehow>;
    VALGRIND_MALLOCLIKE_BLOCK("my_alloc", p, 0, size, 0);
    return p;
}

void* my_free(void* p)
{
    <free p's memory somehow>
    VALGRIND_FREELIKE_BLOCK("my_free", p, 0, 0)
}

By introducing a new alloc type 'AllocOther' to complement the existing
'AllocMalloc', 'AllocNew', 'AllocVecNew', error messages could be made to
say things like:

error blah blah
   at 0x...
   by 0x...
Address 0x12345678 is within a block of size 100 my_alloc'd
   at 0x...
   by 0x...

This would allow error checking to be almost as good as it is for malloc
et al (superblocks could be marked inaccessible at first with the
VALGRIND_MARK_NOACCESS request).  The only shortcomings would be:

1. redzones -- Valgrind's malloc pads heap blocks with redzones to help
   detect overruns and underruns;  the 'rz1' and 'rz2' args above would
   allow a custom allocator to use them if it could.  The rz1 and rz2 args
   would have to match in VALGRIND_MALLOCLIKE_BLOCK and
   VALGRIND_FREELIKE_BLOCK.

2. accesses to freed memory -- Valgrind's allocator deliberately postpones
   the reuse of freed blocks to help catch any accesses after their free.
   A custom allocator could also do this, although it wouldn't be
   necessary.

This seems quite neat and doable to me -- it would fit in fairly easily
with the heap-block-tracking Valgrind already has.  I'll put it on my "to
consider" list... if anyone else would find this useful, speak up, and
that will increase the likelihood of it being implemented.

N

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

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

Julian Seward wrote:
> Attached is a patch which allows you to change stdin to whatever
> you like, if you thing V is closing it.  

I tried the new --gdb-command= option, setting it
to a shell script containing
   DISPLAY=x.y.z.w:0.0 xterm -e gdb "$@"
and it worked nicely.  I'll try the other option next.
I've already posted an interesting stack dump to de...@op... using this.

+1 for getting this into the upcoming release of valgrind!

Thanks,
Dan


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

[Valgrind-users] Using Valgrind with my Own Memory Management

[Seto <Wun...@sy...>]

Hi,

Has anyone been using Valgrind successfully with his/her
own memory management or maybe has some ideas on what
should people do when using Valgrind with their own memory
management, so Valgrind will report useful memory information?

-Seto

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

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

awesome, thanks ;-)

Jeff

On Mon, 2003-05-12 at 16:40, Nicholas Nethercote wrote:
> On 12 May 2003, Jeffrey Stedfast wrote:
> 
> > > I wouldn't say it gets confused;  it's a syntax error, because
> > > suppressions don't support stack traces with more than four entries.
> > > Admittedly the error message isn't great, but I don't think this is a
> > > behaviour that needs fixing.
> >
> > sure, except that it breaks on 4 callers ;-)
> 
> Oh yeah.  I've fixed it now in the HEAD, thanks.
> 
> N
-- 
Jeffrey Stedfast
Evolution Hacker - Ximian, Inc.
fe...@xi...  - www.ximian.com

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

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

On 12 May 2003, Jeffrey Stedfast wrote:

> > I wouldn't say it gets confused;  it's a syntax error, because
> > suppressions don't support stack traces with more than four entries.
> > Admittedly the error message isn't great, but I don't think this is a
> > behaviour that needs fixing.
>
> sure, except that it breaks on 4 callers ;-)

Oh yeah.  I've fixed it now in the HEAD, thanks.

N

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

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

On Mon, 2003-05-12 at 15:59, Nicholas Nethercote wrote:
> On 8 May 2003, Jeffrey Stedfast wrote:
> 
> > 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.
> 
> I wouldn't say it gets confused;  it's a syntax error, because
> suppressions don't support stack traces with more than four entries.
> Admittedly the error message isn't great, but I don't think this is a
> behaviour that needs fixing.

sure, except that it breaks on 4 callers ;-)

the current parser only accepts 3, the 4th line MUST be a "}" line or
the next pass thru the outer loop will encounter the "}" and abort since
it doesn't match "{"

      for (i = 0; i < VG_N_SUPP_CALLERS; i++) {
         eof = VG_(get_line) ( fd, buf, N_BUF );
         if (eof) goto syntax_error;
         if (i > 0 && STREQ(buf, "}")) 
            break;
         supp->caller[i] = VG_(arena_strdup)(VG_AR_CORE, buf);
         if (!setLocationTy(&(supp->caller[i]), &(supp->caller_ty[i])))
            goto syntax_error;
      }

note that if VG_N_SUPP_CALLERS == 4, then the loop only gets executed a
max of 4 times - meaning a max of 4 lines read. Since the only check for
the "}"-line is inside the loop, if that "}"-line isn't read by the 4th
line, then the parser will fail for that suppressions file.

example:

{
  RuleName
  skin:supp_kind
  fun:foo            i = 0
  fun:bar            i = 1
  fun:baz            i = 2
  fun:func           i = 3; last pass thru the loop.
}                    i = 4; oops. no pass thru the loop. line not
caught.

I guess another fix would be to just read a max of one more line after
the loop to check for the "}" (you wouldn't want to change the for-loop
to accept <= VG_N_SUPP_CALLERS or you could overflow the cllaers array).

Hope my explanation helps,

Jeff

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

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

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

On 8 May 2003, Jeffrey Stedfast wrote:

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

I wouldn't say it gets confused;  it's a syntax error, because
suppressions don't support stack traces with more than four entries.
Admittedly the error message isn't great, but I don't think this is a
behaviour that needs fixing.

N

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

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

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

> Thanks so much for this info; I do indeed implement __errno_location()
> but I wasn't sure it's always getting used.  This passing of a 
> descriptor block does sound like NPTL, tho, and we're operating 
> glibc-2.3.2 in old PosixThreads mode so far.  We have confirmation
> from Nick that the errno test program fails on glibc-2.2.X, so
> something else must be broken.

The idea may have come from NPTL but the glibc 2.3.2 that RedHat
shipped as an update for RH8 comes with a version of linuxthreads
that works in the same way.

The main problem is that there isn't an errno_location function
pointer in the descriptor block - instead it uses the thread_descr
function to get the address of the thread descriptor and then expects
to find the thread's errno at a particular offset in that block.

Tom

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

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

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

Dan 

Attached is a patch which allows you to change stdin to whatever
you like, if you thing V is closing it.  

J

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

[Valgrind-users] Patch to make debugging curses programs easier
Date: Sun May 11 18:31:24 2003
From: Sami Liedes <sl...@cc...>
To: val...@li...

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] openoffice and valgrind1.9.6 - strange problems. Using rh8.

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

Troels Walsted Hansen wrote:
>>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.
> 
> 
> RH8 ships with glibc 2.3.1, but 2.3.2 is available as a security update,
> so many people probably have 2.3.2.
> 
> https://rhn.redhat.com/errata/RHSA-2003-089.html
> 

[dank@krunch dank]$ cat /etc/issue
Red Hat Linux release 8.0 (Psyche)
Kernel \r on an \m

[dank@krunch dank]$ rpm -q -a | grep glibc
glibc-2.2.93-5
glibc-devel-2.2.93-5
glibc-common-2.2.93-5
glibc-kernheaders-2.4-7.20

I don't think my system is updated.  Thus I suspect Red Hat 8 ships
with a prerelease version of glibc 2.3.0 called 2.2.93.
(And since my problem happens on rh7.2 as well, I don't think
the errno handling is the problem.)
- 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...>]

On Monday 12 May 2003 8:23 am, Tom Hughes wrote:
> In message <200...@ac...>
>
>         Julian Seward <js...@ac...> wrote:
> > 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.
>
> The errno handling in glibc 2.3.2 is horrible. Some of the routines
> in the library don't go through the procedure linkage table when they
> call the helper function that gets the address of the current thread's
> errno, so they always get glibc's version of that routine instead of
> the one that you have tried to replace it with.
>
> This works normally because libpthread calls __libc_pthread_init at
> startup and gives it a descriptor block which includes a function
> pointer which glibc uses to find the thread descriptor and hence the
> errno to use, but if you don't call that function, and if your thread
> descriptor don't match the real libpthread ones, then it all falls
> apart.

Thanks so much for this info; I do indeed implement __errno_location()
but I wasn't sure it's always getting used.  This passing of a 
descriptor block does sound like NPTL, tho, and we're operating 
glibc-2.3.2 in old PosixThreads mode so far.  We have confirmation
from Nick that the errno test program fails on glibc-2.2.X, so
something else must be broken.

> This is why wine now deliberately writes a jmp instruction over the
> first instruction of glibc's internal errno address getting routine
> so that it guarantee to get control at that point...

Hmm.  

J

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

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

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

RH8 ships with glibc 2.3.1, but 2.3.2 is available as a security update,
so many people probably have 2.3.2.

https://rhn.redhat.com/errata/RHSA-2003-089.html

-- 
Troels

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

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

Dan Kegel wrote:
> 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.

Damn, damn, damn.  Nope.  Here's the deal: even on red hat 7.2,
only the first couple of errors invoke gdb properly.  After
that, when gdb is invoked, something is wrong with stdin;
gdb thinks it's at EOF.  Think openoffice is closing stdin?

For what it's worth, here's the bug I'm really going after:
http://www.openoffice.org/project/www/issues/show_bug.cgi?id=14046
To reproduce it, just load the file FR0453p.doc into ooo1.1beta1 or
the later snapshot build 644_m11.
Without valgrind, you have to click on the first page, click Format/arrange/send to back
(or any of the other arrange commands, probably), then undo,
to trigger the crash.  With Valgrind, I get

==6614== Invalid memory access of size 2
==6614==    at 0x41020329: (within /usr/X11R6/lib/libX11.so.6.2)
==6614==    by 0x4101F934: (within /usr/X11R6/lib/libX11.so.6.2)
==6614==    by 0x4102043A: XSubtractRegion (in /usr/X11R6/lib/libX11.so.6.2)
==6614==    by 0x4102049B: XXorRegion (in /usr/X11R6/lib/libX11.so.6.2)
==6614==    Address 0x42C1D970 is 0 bytes after a block of size 16 alloc'd
==6614==    at 0x40150E99: realloc (vg_clientfuncs.c:276)
==6614==    by 0x4101A78A: (within /usr/X11R6/lib/libX11.so.6.2)
==6614==    by 0x4101AEB7: XPolygonRegion (in /usr/X11R6/lib/libX11.so.6.2)
==6614==    by 0x40590A17: SalGraphics::DrawPolyPolygon(unsigned long, unsigned long const*, SalPoint const**, OutputDevice const*) (in /home/dank/opt/OpenOffice.org1.1Beta/program/libvcl644li.so)
==6614==

as soon as the file finishes loading; you don't even have to do the
send-to-back/undo thing.  Saying 'y' to valgrind at that point
starts gdb, but it goes haywire as if the keyboard isn't really
attached anymore.  I'd like to get a backtrace with gdb there.


- 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

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

On Mon, 12 May 2003, Julian Seward wrote:

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

Hmm, I don't think so:

[~/grind/head] a.out
f1 = 0x804b8a8, errno1 = 4
wurble1: Interrupted system call
f2 = (nil), errno2 = 2
wurble2: No such file or directory
f3 = (nil), errno3 = 2
wurble3: No such file or directory

[~/grind/head] vg6 a.out
==557== Memcheck, a.k.a. Valgrind, a memory error detector for x86-linux.
==557== Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward.
==557== Using valgrind-cvs-head-2003-04-23, a program supervision framework for x86-linux.
==557== Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward.
==557== Estimated CPU clock rate is 1405 MHz
==557== For more details, rerun with: -v
==557==
f1 = 0x40fd8194, errno1 = 0
wurble1: Success
f2 = (nil), errno2 = 2
wurble2: No such file or directory
f3 = (nil), errno3 = 2
wurble3: No such file or directory
==557==
==557== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 6 from 2)
==557== malloc/free: in use at exit: 564 bytes in 2 blocks.
==557== malloc/free: 9 allocs, 7 frees, 2408 bytes allocated.
==557== For a detailed leak analysis,  rerun with: --leak-check=yes
==557== For counts of detected errors, rerun with: -v

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

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

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

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

The errno handling in glibc 2.3.2 is horrible. Some of the routines
in the library don't go through the procedure linkage table when they
call the helper function that gets the address of the current thread's
errno, so they always get glibc's version of that routine instead of
the one that you have tried to replace it with.

This works normally because libpthread calls __libc_pthread_init at
startup and gives it a descriptor block which includes a function
pointer which glibc uses to find the thread descriptor and hence the
errno to use, but if you don't call that function, and if your thread
descriptor don't match the real libpthread ones, then it all falls
apart.

This is why wine now deliberately writes a jmp instruction over the
first instruction of glibc's internal errno address getting routine
so that it guarantee to get control at that point...

Tom

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

[Valgrind-users] Newbie questions. Errors in _STL::basic_string, xlib, etc, etc.

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

Hi all!
Now that I have my nice shiny new valgrind1.9.6 running on Red Hat 7.2
with OpenOffice1.1beta1, I'd like to figure out whether the errors
that pop up are real or not.

Here's the first one that shows up:

==6424== Invalid memory access of size 1
==6424==    at 0x4119C4C5: _STL::basic_string<wchar_t, _STL::char_traits<wchar_t>, _STL::allocator<wchar_t> >::basic_string(wchar_t const*, _STL::allocator<wchar_t> const&) (in /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so)
==6424==    by 0x41162A2F: (within /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so)
==6424==    by 0x41162B11: (within /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so)
==6424==    by 0x41171E46: (within /home/dank/opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so)
==6424==    Address 0xBFFFF4C9 is just below %esp.  Possibly a bug in GCC/G++
==6424==    v 2.96 or 3.0.X.  To suppress, use: --workaround-gcc296-bugs=yes
==6424==
==6424== ---- Attach to GDB ? --- [Return/N/n/Y/y/C/c] ---- y
==6424== starting GDB with cmd: /usr/bin/gdb -nw /proc/6424/exe 6424
GNU gdb Red Hat Linux 7.x (5.0rh-15) (MI_OUT)
...
(gdb) bt
#0  vg_do_syscall3 (syscallno=65535, arg1=1, arg2=3221222680, arg3=1091971632) at vg_mylibc.c:92
#1  0x0000191c in ?? () at eval.c:41
#2  0x4119c4c5 in _STL::basic_string<wchar_t, _STL::char_traits<wchar_t>, _STL::allocator<wchar_t> >::basic_string(wchar_t const*, _STL::allocator<wchar_t> const&) ()
    from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so
#3  0x41162a30 in _STL::numpunct<wchar_t>::do_falsename() const ()
    from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so
#4  0x41162b12 in _STL::numpunct<wchar_t>::do_falsename() const ()
    from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so
#5  0x41171e47 in _STL::tanh(_STL::complex<long double> const&) ()
    from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so
#6  0x411556b6 in _init () from /opt/OpenOffice.org1.1Beta/program/libstlport_gcc.so
#7  0x4000d9e7 in _dl_init () at eval.c:41

That one looks real to me (although I can't for the life of me
figure out what punctuation has to do with hyperbolic tangents).
I think OpenOffice contains its own copy of
STL, which appears to have an off-by one bug.  Or is it
really just a gcc bug, and I should do as the message suggests?
Anyone know of valgrind issues in stlport.org's stl implementation?

Second problem: at startup time, I get this:

==18415== Syscall param writev(vector[...]) contains uninitialised or unaddressable byte(s)
==18415==    at 0x40170F87: vgAllRoadsLeadToRome_writev (vg_intercept.c:108)
==18415==    by 0x40170FC4: __writev (vg_intercept.c:733)
==18415==    by 0x40C2588F: (within /usr/X11R6/lib/libX11.so.6.2)
==18415==    by 0x40C264CE: _X11TransWritev (in /usr/X11R6/lib/libX11.so.6.2)
==18415==    Address 0x43F51058 is 32 bytes inside a block of size 2048 alloc'd
==18415==    at 0x4015E780: calloc (vg_clientfuncs.c:245)
==18415==    by 0x40BF852B: XOpenDisplay (in /usr/X11R6/lib/libX11.so.6.2)
==18415==    by 0x4048C395: SalXLib::Init(int*, char**) (in /opt/OpenOffice.org644/program/libvcl644li.so)
==18415==    by 0x4048BFD8: SalData::Init(int*, char**) (in /opt/OpenOffice.org644/program/libvcl644li.so)

This might just be normal X library behavior; see
http://keithp.com/~keithp/talks/usenix2003/html/net.html,
which says "Gian Filippo Pinzari [Pin03] has recently pointed out that
Xlib does not zero out unused bytes in the protocol stream but
transmits the left over bytes in the protocol buffer where the requests are formed. "
Doesn't sound valgrind-friendly offhand.  Ripe for suppression?

Guidence from the masters would be welcome.  I'll probably be bugging
this list quite a bit in the next few days as I come up to speed
on valgrind/ooo.

Thanks,
Dan

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