valgrind-users — General discussion list for Valgrind users

Re: [Valgrind-users] RedHat 8.0 pthread "problem"

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

Beau D. Simensen wrote:
> The program I've written is currently doing the following:
>  
>  o Main thread loops, checking a list of remote request handlers to see 
> if one of them needs to be queued up for a client [most of them are 
> scheduled based on time, some of them based on other criteria]. If a 
> request handler is ready to be executed, it pushes a request onto one of 
> two client connection queues.
>  
>  o Two client connection threads wait for new requests to show up in 
> their queues. When one is found, a connection is opened if one isn't 
> already opened, the request is sent to the server, and the response is 
> read. Connection closes after X number of seconds that the connection 
> hasn't been used.

I have to ask -- why are you using threads here?
What you've described would work well, and would
scale better, using nonblocking i/o and sys_epoll...
- Dan

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

[Valgrind-users] RedHat 8.0 pthread "problem"

[Beau D. S. <sim...@ha...>]

Greetings,

I'm new to valgrind, but it was very highly recommended. With the =
exception of the following oddity, I'm quite happy so far.

First off, I'm pretty new to C++ and threads. I'm more of a Perl guy. =
Trying to figure out my problem, I've seen a number of posts where =
people say, "but it works when I don't use valgrind!" Given some of the =
problems I've had over the last four months dealing with random C++ or =
thread problems, I'm not about to assume that just because my code runs =
in its current state that there isn't anything wrong with it. =3D) =
However, I'm not entirely convinced that it isn't something tweaky in =
valgrind's pthread emulation since there are so many thread disclaimers =
all over the place...

The program I've written is currently doing the following:

 o Main thread loops, checking a list of remote request handlers to see =
if one of them needs to be queued up for a client [most of them are =
scheduled based on time, some of them based on other criteria]. If a =
request handler is ready to be executed, it pushes a request onto one of =
two client connection queues.

 o Two client connection threads wait for new requests to show up in =
their queues. When one is found, a connection is opened if one isn't =
already opened, the request is sent to the server, and the response is =
read. Connection closes after X number of seconds that the connection =
hasn't been used.


Now, this works outside of valgrind. Pretty well -- I haven't noticed =
any problems with it and other memory debugging stuff seems to think it =
is OK [for the most part]. I can actually make it "work" in valgrind, =
but only if I have --trace-pthread=3Dall set. However, this dumps far =
too much info to be useful for me as I have *alot* of mutex =
locking/unlocking. [I've since learned how to use semaphores. When I get =
a spare week or two I'll rewrite it all again... =3D)]

If it ran w/o all the pthread trace stuff, I'd be super happy! I'd =
prolly be able to move on and start using valgrind all the time [there =
are lots of other little thingies in the log that need addressing... =
memleaks, etc.] but I don't wanna run with all pthread-trace. And I'm =
not sure why it should matter. How does --trace-pthread=3Dall differ =
from --trace-pthread=3Dsome or --trace-pthread=3Dnone?

The way the application behaves when -trace-pthread=3D is set to =
anything but 'all' is that one of the threads just locks. Or something? =
The first request [authenticate] actually goes out and is read just like =
it should. However, the next two requests get lost somewhere. The caller =
[main thread] seems to think that the second/third request has gone =
'stale', which is what happens if the request isn't marked finished =
within X number of time.

The odd thing is that the second client connection thread seems to not =
have this problem [that I can see]. It executes its one request every X =
number of seconds as it should, as per the main thread says it should.

Again, it works like a charm outside of valgrind. It works with valgrind =
if --trace-pthread=3Dall . No worky if -trace-pthread=3D none or some. I =
can try and provide as much info as needed. I'd really like to be able =
to use valgrind because it looks like it can do alot of really great =
things, but I can't really use it to test too much if my code doesn't =
actually run under it. I'll provide any other information needed if more =
info is needed.

System Environment:

RedHat-8.0
 o glibc-2.2.93-5
 o glibc-devel-2.2.93-5
 o gcc-g++-3.2-7
 o valgrind-1.9.6


Thanks!


Beau D. Simensen
http://www.halogen.org/

Re: [Valgrind-users] strcat bug

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

Morten Eriksen wrote:
> * Leonard mckinley:
> 
>>[snip]
>>  char name  [ 64 ];
>>
>>  strcpy( buffer, "[" );
>>  strcpy( name, "why did the chicken cross the road" );
>>[snip]
> 
> 
> * Dan Kegel:
> 
>>Say, isn't name uninitialized there?

Sorry, my eyes say "strcat" instead of "strcpy".  Guess
I should check my posts more thoroughly!
- Dan

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

Re: [Valgrind-users] strcat bug

[Morten E. <mo...@si...>]

* Leonard mckinley:
> 
> [snip]
>   char name  [ 64 ];
> 
>   strcpy( buffer, "[" );
>   strcpy( name, "why did the chicken cross the road" );
> [snip]

* Dan Kegel:
> 
> Say, isn't name uninitialized there?

No, initialization happens with the

   strcpy( name, "why did the chicken cross the road" );

statement.

Morten

Re: [Valgrind-users] Suppressions

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

On Tue, 10 Jun 2003, Alex Ivershen wrote:

> I am having troubles suppressing certain messages, may be the reason is that the
> callstack contains C++ member fucntions and I am writing them in a wrong way in
> the suppression file ...  Valgrind reads the suppression file just fine, but
> errors and memory leaks still pop up. BTW, I am using 1.9.6.

Easy solution:  grab CVS head from Sourceforge, build as per README
instructions, use the --gen-suppressions=yes option.

More details below.

> Here is an error that I am trying to suppress:
>
> ==17423== Syscall param ioctl(CDROMREADTOCENTRY (cdte_track, char)) contains
> uninitialised or unaddressable byte(s)
> ==17423==    at 0x40387D04: __GI___ioctl (in /lib/libc-2.3.2.so)
> ==17423==    by 0x80A8145: KIpmPerThreadData::KIpmPerThreadData(int, int, void
> (*)(void *, IpmCongestionType), void *) (../KIpmPerThreadData.cc:208)
> ==17423==    by 0x80A6B52: ipmInit(void) (../common/IpmPerThreadData.h:183)
> ==17423==    by 0x8060C6A: initProcessControl(char const *, unsigned long,
> short, short) (../common/ProcessControl.cc:249)
> ==17423==    Address 0x2 is not stack'd, malloc'd or free'd
>
> Here is a suppression entry:
>
> {
>     ioctl_CDROMREADTOCENTRY/ipmInit
>     Addrcheck,Memcheck:Cond
>     fun:__GI___ioctl
>     fun:KIpmPerThreadData::KIpmPerThreadData
>     fun:ipmInit
> }

1. C++ names must be _mangled_.  Use --demangle=no to find them out.

2. "Cond" is the wrong type, you want "Syscall" (or something similar, I
can't remember the exact name now).

3. "Syscall" type suppressions (confusingly) needs an extra line before
the first "fun:" line, which I think (off the top of my head) specifies
which argument is the problem.

> Here is a memory leak I am trying to suppress:
>
> ==17423== 12 bytes in 1 blocks are possibly lost in loss record 4 of 46
> ==17423==    at 0x4015E310: malloc (vg_clientfuncs.c:103)
> ==17423==    by 0x80BB74B: __builtin_new (../../gcc-2.95.3/gcc/cp/new1.cc:77)
> ==17423==    by 0x8063369: ProcessorConfigDb::BuildProcessorControlName(void)
> (../include/NsDestList.h:173)
> ==17423==    by 0x8065193: ProcessorConfigDb::UpdateSystemNames(short)
> (../common/ProcessorConfigDb.cc:873)
>
> Here is a suppression entry (there are similar errors from similar functions,
> hence the wildcard)
>
> {
>     ProcessorConfigDb/BuildDbServerName
>     Memcheck:Leak
>     fun:malloc
>     fun:__builtin_new
>     fun:ProcessorConfigDb::Build*
> }

This one's closer, again I think its the mangling that's the problem.

N

[Valgrind-users] Suppressions

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

R2VudGxlbWVuLA0KDQpJIGFtIGhhdmluZyB0cm91YmxlcyBzdXBwcmVzc2luZyBjZXJ0YWlu
IG1lc3NhZ2VzLCBtYXkgYmUgdGhlIHJlYXNvbiBpcyB0aGF0IHRoZQ0KY2FsbHN0YWNrIGNv
bnRhaW5zIEMrKyBtZW1iZXIgZnVjbnRpb25zIGFuZCBJIGFtIHdyaXRpbmcgdGhlbSBpbiBh
IHdyb25nIHdheSBpbg0KdGhlIHN1cHByZXNzaW9uIGZpbGUgLi4uICBWYWxncmluZCByZWFk
cyB0aGUgc3VwcHJlc3Npb24gZmlsZSBqdXN0IGZpbmUsIGJ1dA0KZXJyb3JzIGFuZCBtZW1v
cnkgbGVha3Mgc3RpbGwgcG9wIHVwLiBCVFcsIEkgYW0gdXNpbmcgMS45LjYuDQoNCkhlcmUg
aXMgYW4gZXJyb3IgdGhhdCBJIGFtIHRyeWluZyB0byBzdXBwcmVzczoNCg0KPT0xNzQyMz09
IFN5c2NhbGwgcGFyYW0gaW9jdGwoQ0RST01SRUFEVE9DRU5UUlkgKGNkdGVfdHJhY2ssIGNo
YXIpKSBjb250YWlucw0KdW5pbml0aWFsaXNlZCBvciB1bmFkZHJlc3NhYmxlIGJ5dGUocykN
Cj09MTc0MjM9PSAgICBhdCAweDQwMzg3RDA0OiBfX0dJX19faW9jdGwgKGluIC9saWIvbGli
Yy0yLjMuMi5zbykNCj09MTc0MjM9PSAgICBieSAweDgwQTgxNDU6IEtJcG1QZXJUaHJlYWRE
YXRhOjpLSXBtUGVyVGhyZWFkRGF0YShpbnQsIGludCwgdm9pZA0KKCopKHZvaWQgKiwgSXBt
Q29uZ2VzdGlvblR5cGUpLCB2b2lkICopICguLi9LSXBtUGVyVGhyZWFkRGF0YS5jYzoyMDgp
DQo9PTE3NDIzPT0gICAgYnkgMHg4MEE2QjUyOiBpcG1Jbml0KHZvaWQpICguLi9jb21tb24v
SXBtUGVyVGhyZWFkRGF0YS5oOjE4MykNCj09MTc0MjM9PSAgICBieSAweDgwNjBDNkE6IGlu
aXRQcm9jZXNzQ29udHJvbChjaGFyIGNvbnN0ICosIHVuc2lnbmVkIGxvbmcsDQpzaG9ydCwg
c2hvcnQpICguLi9jb21tb24vUHJvY2Vzc0NvbnRyb2wuY2M6MjQ5KQ0KPT0xNzQyMz09ICAg
IEFkZHJlc3MgMHgyIGlzIG5vdCBzdGFjaydkLCBtYWxsb2MnZCBvciBmcmVlJ2QNCg0KSGVy
ZSBpcyBhIHN1cHByZXNzaW9uIGVudHJ5Og0KDQp7DQogICAgaW9jdGxfQ0RST01SRUFEVE9D
RU5UUlkvaXBtSW5pdA0KICAgIEFkZHJjaGVjayxNZW1jaGVjazpDb25kDQogICAgZnVuOl9f
R0lfX19pb2N0bA0KICAgIGZ1bjpLSXBtUGVyVGhyZWFkRGF0YTo6S0lwbVBlclRocmVhZERh
dGENCiAgICBmdW46aXBtSW5pdA0KfQ0KDQpIZXJlIGlzIGEgbWVtb3J5IGxlYWsgSSBhbSB0
cnlpbmcgdG8gc3VwcHJlc3M6DQoNCj09MTc0MjM9PSAxMiBieXRlcyBpbiAxIGJsb2NrcyBh
cmUgcG9zc2libHkgbG9zdCBpbiBsb3NzIHJlY29yZCA0IG9mIDQ2DQo9PTE3NDIzPT0gICAg
YXQgMHg0MDE1RTMxMDogbWFsbG9jICh2Z19jbGllbnRmdW5jcy5jOjEwMykNCj09MTc0MjM9
PSAgICBieSAweDgwQkI3NEI6IF9fYnVpbHRpbl9uZXcgKC4uLy4uL2djYy0yLjk1LjMvZ2Nj
L2NwL25ldzEuY2M6NzcpDQo9PTE3NDIzPT0gICAgYnkgMHg4MDYzMzY5OiBQcm9jZXNzb3JD
b25maWdEYjo6QnVpbGRQcm9jZXNzb3JDb250cm9sTmFtZSh2b2lkKQ0KKC4uL2luY2x1ZGUv
TnNEZXN0TGlzdC5oOjE3MykNCj09MTc0MjM9PSAgICBieSAweDgwNjUxOTM6IFByb2Nlc3Nv
ckNvbmZpZ0RiOjpVcGRhdGVTeXN0ZW1OYW1lcyhzaG9ydCkNCiguLi9jb21tb24vUHJvY2Vz
c29yQ29uZmlnRGIuY2M6ODczKQ0KDQpIZXJlIGlzIGEgc3VwcHJlc3Npb24gZW50cnkgKHRo
ZXJlIGFyZSBzaW1pbGFyIGVycm9ycyBmcm9tIHNpbWlsYXIgZnVuY3Rpb25zLA0KaGVuY2Ug
dGhlIHdpbGRjYXJkKQ0KDQp7DQogICAgUHJvY2Vzc29yQ29uZmlnRGIvQnVpbGREYlNlcnZl
ck5hbWUNCiAgICBNZW1jaGVjazpMZWFrDQogICAgZnVuOm1hbGxvYw0KICAgIGZ1bjpfX2J1
aWx0aW5fbmV3DQogICAgZnVuOlByb2Nlc3NvckNvbmZpZ0RiOjpCdWlsZCoNCn0NCg0KUGxl
YXNlLCBsZXQgbWUga25vdyB3aGF0IEkgYW0gbWlzc2luZyBoZXJlISBUaGFua3MgYSBidW5j
aCENCg0KUmVnYXJkcywNCkFsZXgNCg0KLS0NCkFsZXggRy4gSXZlcnNoZW4gICAgICAgICAg
ICAgICAgICAgICAgICAgICAgSW5ldCBUZWNobm9sb2dpZXMsIEluYy4NCk5ldHdvcmsgUHJv
ZHVjdHMgRGVwdC4gICAgICAgICAgICAgICAgICAgICAgMTUwMCBOLiBHcmVlbnZpbGxlIEF2
ZS4NCkluZXQgVGVjaG5vbG9naWVzIEluYy4gICAgICAgICAgICAgICAgICAgICAgUmljaGFy
ZHNvbiwgVFggNzUwODENClBob25lOiArMS00NjktMzMwLTQyOTUgICAgICAgICAgICAgICAg
ICAgICAgVVNBDQoNCiJDb21wdXRlciBnYW1lcyBkb24ndCBhZmZlY3Qga2lkczsgSSBtZWFu
IGlmIFBhYy1NYW4gYWZmZWN0ZWQgdXMgYXMga2lkcywgd2UnZA0KYWxsIGJlIHJ1bm5pbmcg
YXJvdW5kIGluIGRhcmtlbmVkIHJvb21zLCBtdW5jaGluZyBtYWdpYyBwaWxscyBhbmQgbGlz
dGVuaW5nIHRvDQpyZXBldGl0aXZlIGVsZWN0cm9uaWMgbXVzaWMuIiAtLSBLcmlzdGlhbiBX
aWxzb24sIE5pbnRlbmRvLCBJbmMNCg0KDQo=

Re: [Valgrind-users] strcat bug

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

Leonard mckinley wrote:
> #include <string.h>
> 
> int main()
> {
>   char buffer[ 1024 ];
>   char name  [ 64 ];
> 
>   strcpy( buffer, "[" );
>   strcpy( name, "why did the chicken cross the road" );
>   strcat( name, buffer );
> }

Say, isn't name uninitialized there?
- Dan

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

Re: [Valgrind-users] Question about uninitialized references

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

On 10 Jun 2003, Jeremy Fitzhardinge wrote:

> On Tue, 2003-06-10 at 07:58, Nicholas Nethercote wrote:
> > validity is checked when a value is:
> >
> > 1. used in a condition (affects control flow)
> >
> > 2. used by a syscall (ie. argument) (affects side effects seen by outside
> >    world)
>
> And when it is used as a pointer.

Oh yeah, because that can affect the "external behaviour" (by crashing it
if the pointer is bogus :)

N

Re: [Valgrind-users] Question about uninitialized references

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

On Tue, 2003-06-10 at 07:58, Nicholas Nethercote wrote:
> validity is checked when a value is:
> 
> 1. used in a condition (affects control flow)
> 
> 2. used by a syscall (ie. argument) (affects side effects seen by outside
>    world)

And when it is used as a pointer.

    J

RE: [Valgrind-users] Question about uninitialized references

[Vincent Penquerc'h <Vin...@ar...>]

> Just a curious question.  What is valgrind's test for "dealing"
> with uninitialized data?  It appears reading it moving it around 
> is OK, but using it to perform "a computation" is an error?  But 
> what is "a computation" in this context?

Whatever would make the behavior of the program undefined, I'd
say. This is covered in the docs, along with a note that moving
uninitialized stuff is often done. Like, say, in the following:

typedef struct {
  int is_used;
  int data;
} foo;

foo f,g;
f.is_used = 0;
g=f;


-- 
Vincent Penquerc'h 

Re: [Valgrind-users] Question about uninitialized references

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

On Tue, 10 Jun 2003, Leonard mckinley wrote:

> Just a curious question.  What is valgrind's test for "dealing"
> with uninitialized data?  It appears reading it moving it around
> is OK, but using it to perform "a computation" is an error?  But
> what is "a computation" in this context?

validity is checked when a value is:

1. used in a condition (affects control flow)

2. used by a syscall (ie. argument) (affects side effects seen by outside
   world)

That's it.  It might not seem like much, but it's enough, if you think
about it - that catches all cases where an invalid value can affect the
behaviour of your program, as viewed by the outside world.

Note especially that structs can have "holes" in them (due to padding
inserted by the compiler to improve field alignments) so copying has to be
ok.

> This guess seems consistent with the fact that valgrind doesn't flag
> passing uninitialized data to a function so long as the parameter isn't
> used.  But I'd like to know the full story.

N

[Valgrind-users] Question about uninitialized references

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

#include <stdio.h>

struct stuff
{
  double value;
};


int main()
{
  stuff prev,curr;

  //curr.value = 0;
  prev = curr;
  curr.value = 1;
  if ( prev.value != curr.value )
    printf( "Different\n" );
}

In the above example, prev = curr doesn't generate a ref to uninit data
warning.  But the condition on the if line does.

Just a curious question.  What is valgrind's test for "dealing"
with uninitialized data?  It appears reading it moving it around 
is OK, but using it to perform "a computation" is an error?  But 
what is "a computation" in this context?

This guess seems consistent with the fact that valgrind doesn't flag
passing uninitialized data to a function so long as the parameter isn't
used.  But I'd like to know the full story.

Thanks,

Randall


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

[Valgrind-users] Re: strcat bug

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

--- Nicholas Nethercote <nj...@ca...> wrote:
> >   strcat( name, buffer );
> > valgrind CVS says:
> > ==3194== Source and destination overlap in
> 
> You're right, it's now fixed (I think/hope) in CVS.  Thanks for the
> report.

That did it.  Thanks!

Randall

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

Re: [Valgrind-users] strcat bug

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

On Tue, 10 Jun 2003, Leonard mckinley wrote:

> I extracted a valgrind-flagged problem into this simple little C
> program:
>
> #include <string.h>
>
> int main()
> {
>   char buffer[ 1024 ];
>   char name  [ 64 ];
>
>   strcpy( buffer, "[" );
>   strcpy( name, "why did the chicken cross the road" );
>   strcat( name, buffer );
> }
>
> valgrind CVS says:
>
> ==3194== Source and destination overlap in strcat(0xbfffede0,0xbfffee20)
> ==3194==    at 0x40022FD4: strcat (mc_replace_strmem.c:59)
> ==3194==    by 0x8048412: main (tst.C:10)
> ==3194==    by 0x4031D4A1: __libc_start_main (in /lib/libc.so.6)
> ==3194==    by 0x8048320: (within /home/rhh/tst)
>
> Hmmm...  Either I need more coffee this morning (a distinct
> possibility), or this could be a valgrind bug.

You're right, it's now fixed (I think/hope) in CVS.  Thanks for the
report.

N

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

[John R. <jr...@Bi...>]

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


0x94 is "xchg %eax,%esp", which is switching stacks: some form of threads
that is specific to the application.

Re: [Valgrind-users] Error limits with CVS head

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

On Tue, 10 Jun 2003, Leonard mckinley wrote:

> Really, from a usage perspective, it doesn't matter how many issues
> valgrind detected if it doesn't report any of them because they're
> all suppressed and thus presumably not errors.  I don't think these
> should reduce the number of unsuppressed potential errors that the user
> does get to see.  But I can turn the limits off so that's OK.
> Just a suggestion to make the limits more useful.

From your earlier email:

> In the coregrind_core.html docs, I notice:
>
>    Note that the 300/30000 limits apply after suppressed errors are
>    removed.

Suppressed errors don't count towards the limit.

N

Re: [Valgrind-users] Error limits with CVS head

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

--- Nicholas Nethercote <nj...@ca...> wrote:
> > Just ran CVS head on an app I have and while the valgrind 
> > output is only 926 lines long (133 flagged issues), 
> > valgrind says:
> >
> >    More than 30000 total errors detected.
> 
> Do you get that many bugs on just one program, or across a range? 
> If it's the former, you've probably just a got a really buggy
> program.  If it's the latter, it's probably a problem with 
> Valgrind itself.

This was running one program.  It's not buggy but it is
large.  And like I said, the file only lists 133 flagged errors,
so the rest of the 30,000 are apparently being suppresssed by
valgrind's default suppression rules.

And of those 133, many of them are things which aren't in this 
program's code, things like:

Conditional jump or move depends on uninitialised value down in ld.so
or the NVidia libGL*, or
Syscall param ioctl(generic) contains uninitialised or unaddressable
byte(s) down in libc with only libc on the stack.

Really, from a usage perspective, it doesn't matter how many issues
valgrind detected if it doesn't report any of them because they're
all suppressed and thus presumably not errors.  I don't think these
should reduce the number of unsuppressed potential errors that the user
does get to see.  But I can turn the limits off so that's OK.
Just a suggestion to make the limits more useful.

Randall





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

[Valgrind-users] strcat bug

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

I extracted a valgrind-flagged problem into this simple little C
program:

#include <string.h>

int main()
{
  char buffer[ 1024 ];
  char name  [ 64 ];

  strcpy( buffer, "[" );
  strcpy( name, "why did the chicken cross the road" );
  strcat( name, buffer );
}

valgrind CVS says:

==3194== Source and destination overlap in strcat(0xbfffede0,
0xbfffee20)
==3194==    at 0x40022FD4: strcat (mc_replace_strmem.c:59)
==3194==    by 0x8048412: main (tst.C:10)
==3194==    by 0x4031D4A1: __libc_start_main (in /lib/libc.so.6)
==3194==    by 0x8048320: (within /home/rhh/tst)

Hmmm...  Either I need more coffee this morning (a distinct
possibility), or this could be a valgrind bug.

Randall


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

Re: [Valgrind-users] Error limits with CVS head

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

On Tue, 10 Jun 2003, Leonard mckinley wrote:

> Just ran CVS head on an app I have and while the valgrind output is
> only 926 lines long (133 flagged issues), valgrind says:
>
>    More than 30000 total errors detected.  I'm not reporting any more.
>
> In the coregrind_core.html docs, I notice:
>
>    Note that the 300/30000 limits apply after suppressed errors are
>    removed.
>
> 133 vs. 30000.  Is this a bug?

When the same bug occurs more than once in the same place, it gets
recorded each time, but only reported once.  The limit is 300 distinct
(ie. reported) bugs, or 30000 non-distinct (ie. recorded) bugs, whichever
comes first.

> Note that this is with vg_replace_malloc.c rolled back to rev 1.6
> to work around the new/delete matching issue.  However I was getting
> the 30000 limit before with no where near that many errors in the file.
>
> I'll try running with --error-limit=no for now.

Do you get that many bugs on just one program, or across a range?  If it's
the former, you've probably just a got a really buggy program.  If it's
the latter, it's probably a problem with Valgrind itself.

N

[Valgrind-users] Error limits with CVS head

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

Just ran CVS head on an app I have and while the valgrind output is
only 926 lines long (133 flagged issues), valgrind says:

   More than 30000 total errors detected.  I'm not reporting any more.

In the coregrind_core.html docs, I notice:

   Note that the 300/30000 limits apply after suppressed errors are
   removed.

133 vs. 30000.  Is this a bug?

Note that this is with vg_replace_malloc.c rolled back to rev 1.6
to work around the new/delete matching issue.  However I was getting
the 30000 limit before with no where near that many errors in the file.

I'll try running with --error-limit=no for now.

Thanks,

Randall


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

[Valgrind-users] Re: Recommended gcc version

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

--- Melchior FRANZ <mf...@kd...> wrote:
> > I'll try gcc 2.96.
> 
> Why? Revert vg_replace_malloc.c -r1.7 and be happy (with gcc 3.2).
> 
>   $ cvs up -r1.6 coregrind/vg_replace_malloc.c

Thanks!  Glad it was that simple.  Fortunate for another reason as
well:

   http://gcc.gnu.org/gcc-2.96.html

Randall



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

Re: [Valgrind-users] Recommended gcc version

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

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

Thanks for the replies.  I'll try gcc 2.96.

Here's more info for those working on the CVS head.  This program:

int main()
{
   int *block, *block_list;

   block = new int;
   block_list = new int[ 10 ];
   delete block;
   delete [] block_list;
}

generates these errors:

==29084== Mismatched free() / delete / delete []
==29084==    at 0x40026350: __builtin_delete (vg_replace_malloc.c:233)
==29084==    by 0x40026370: operator delete(void*)
(vg_replace_malloc.c:242)
==29084==    by 0x8048506: main (tst.C:7)
==29084==    by 0x4031D4A1: __libc_start_main (in /lib/libc.so.6)
==29084==    Address 0x411190D4 is 0 bytes inside a block of size 4
alloc'd
==29084==    at 0x40026020: malloc (vg_replace_malloc.c:153)
==29084==    by 0x402B194D: operator new(unsigned) (in
/usr/lib/libstdc++.so.5.0.0)
==29084==    by 0x80484E5: main (tst.C:5)
==29084==    by 0x4031D4A1: __libc_start_main (in /lib/libc.so.6)
==29084== 
==29084== Mismatched free() / delete / delete []
==29084==    at 0x400263EC: __builtin_vec_delete
(vg_replace_malloc.c:252)
==29084==    by 0x4002640C: operator delete[](void*)
(vg_replace_malloc.c:261)
==29084==    by 0x804851A: main (tst.C:8)
==29084==    by 0x4031D4A1: __libc_start_main (in /lib/libc.so.6)
==29084==    Address 0x41119108 is 0 bytes inside a block of size 40
alloc'd
==29084==    at 0x40026020: malloc (vg_replace_malloc.c:153)
==29084==    by 0x402B194D: operator new(unsigned) (in
/usr/lib/libstdc++.so.5.0.0)
==29084==    by 0x402B1AAE: operator new[](unsigned) (in
/usr/lib/libstdc++.so.5.0.0)
==29084==    by 0x80484F5: main (tst.C:6)

using valgrind from CVS yesterday with gcc 3.2 and glibc 2.2.5 (SuSE
8.1).

Randall


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

[Valgrind-users] Re: Recommended gcc version

[Melchior F. <mf...@kd...>]

* Leonard mckinley -- Tuesday 10 June 2003 00:05:
> Pulled CVS today and I'm getting 10s of thousands of Mismatched free
> errors that aren't mismatched, a known issue reported earlier in the
> archives.

I can confirm that cvs/head gives hundreds of bogus error messages
about mismatched allocation. I only checked one of them and saw that
the concerned code creates an automatic variable of a c++ object.
valgrind obviously complains when the auto var is to be destroyed
at function end. The bug was introduced with "vg_replace_malloc.c"
revision 1.7. (1.6 did still work.)

Example error message from debugging FlightGear/gcc 3.2/Linux 2.4.21-pre6:

==10706== Mismatched free() / delete / delete []
==10706==    at 0x400263EC: __builtin_vec_delete (vg_replace_malloc.c:252)
==10706==    by 0x4002640C: operator delete[](void*) (vg_replace_malloc.c:261)
==10706==    by 0x8491E79: ulRTTITypeinfo::ulRTTITypeinfo(char const*, ulRTTITypeinfo const**, void* (*)(int, void*), void* (*)()) (ulRTTI.cxx:50)
==10706==    Address 0x42B4EA2C is 0 bytes inside a block of size 4 alloc'd
==10706==    at 0x40026020: malloc (vg_replace_malloc.c:153)
==10706==    by 0x4033789D: operator new(unsigned) (in /usr/lib/libGLU.so.1.3)
==10706==    by 0x403379FE: operator new[](unsigned) (in /usr/lib/libGLU.so.1.3)
==10706==    by 0x8491E34: ulRTTITypeinfo::ulRTTITypeinfo(char const*, ulRTTITypeinfo const**, void* (*)(int, void*), void* (*)()) (ulRTTI.cxx:67)




And then: line 123 in configure.in from cvs/head causes the
following error when running ./autogen.sh:

  running: autoconf
  configure.in:123: error: possibly undefined macro: AC_PROG_EGREP
  error: while running 'autoconf'

Commenting this check out makes ./autogen.sh work. The funny thing
is, that if I run autoconf manually, then I do neither get a complaint
about AC_PROG_EGREP, nor an error return value.  (WTF??)

m.



PS: I didn't mean to be ungrateful when I complained about my joystick
    patch being ignored for a month. I =am= grateful for that wonderful
    tool and all your work on it!   :-)

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

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

--- Jeremy Fitzhardinge <je...@go...> wrote:
> On Mon, 2003-06-09 at 01:04, Prashant Verma wrote:
> > I was trying to run valgrind with wine. As an
> example
> > app I used Acrobat Reader.exe The following
> command
> > gives a stack overflow problem:
> 
> Does the same thing happen with the Linux native
> version of acroread?  I
> would guess that the core code is the same for the
> two versions, and it
> might indicate whether acroread really needs a huge
> stack, or its some
> artifact of the wine+acroread combination.

It doesn't happen with the native version of acroread,
so I think it indicates the latter point that you
state i.e. some problem with wine +
acroread(windows)+cachegrind combination. 
Note that wine + acroread(windows) runs fine.

Prashant

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

Re: [Valgrind-users] Recommended gcc version

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

On Mon, 9 Jun 2003, Leonard mckinley wrote:

> Pulled CVS today and I'm getting 10s of thousands of Mismatched free
> errors that aren't mismatched, a known issue reported earlier in the
> archives.
>
> What version of gcc are the valgrind developers running with?  I'll
> just rebuild my app tree with that and be done with it.

I use:

  gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85)

Ancient history, eh?  I recently tried 3.2.3 but the compile times were
noticeably slower so I switched back to 2.96.

N