valgrind-users — General discussion list for Valgrind users

[Valgrind-users] File descriptor leakage tracking

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

Hi all,

The attached patch to the CVS head tracks open file descriptors and
dumps them out at the end of the run.  If you don't specify any
command-line options, you get a summary indicating how many fds are
still open.  If you specify --fd-list=yes, you get a more verbose list
showing the filename (if it exists) for each open file descriptor, along
with a backtrace from the point where it was opened.  If the fd was
inherited from the parent process, no backtrace is produced.

The patch knows about file descriptors created by the following system
calls: open, dup, dup2, pipe, socket, socketpair and accept.  It also
knows about file descriptors passed between processes using usix-domain
socket cmsg's.

Please let me know if I've missed any important calls.

The patch also adds VG_(lseek), VG_(readlink) and VG_(getdents) to
vg_mylibc, which some other people might find useful too.

Regards,
 Robert.

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

Re: [Valgrind-users] Re: valgrind / pthreads issue

[Todd R. <ric...@pr...>]

My tests were on both a Gigabyte athlon XP and a Dell 2.53 p4. I was also
about to write a smaller test program, but it looks like you beat me to it -
thx
    Todd

----- Original Message -----
From: "Sefer Tov" <se...@ho...>
To: <val...@li...>
Sent: Saturday, April 19, 2003 11:45 PM
Subject: [Valgrind-users] Re: valgrind / pthreads issue


> Hi!
>
> Oddly enough, I've been experiencing the same problem.
> I'm using Linux Mandrake 9.1, which appears to come with a version of
glibc
> 2.3.2 (but I think this was happening with older glibc's as well).
>
> I've written a tiny skeleton server that pre-creates a few threads
> (successfully) and then enters a poll loop (from which point the threads
are
> not getting any cpu time at all).
>
> It seems that there is some pthreads/poll issue, but this may also be
> related that I'm running everything on a laptop and we have already
noticed
> that there might be some scheduling problems because TSC register being
used
> is variable-rate on machines with power management active.
>
> Thanks,
>     Sefer.
>
>
> >That's very strange.  V has threading problems with glibcs > 2.3.1,
> >though.  So I wonder if that's it.  Do you have an older linux
> >distro you can try it on, something like RH 7.3, or Suse 8.1 ?
> >Basically anything with glibc 2.3.1 or before; 2.2.5 would be
> >even better.
>
> >J
>
> _________________________________________________________________
> Add photos to your messages with MSN 8. Get 2 months FREE*.
> http://join.msn.com/?page=features/featuredemail
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

[Valgrind-users] Re: valgrind / pthreads issue

[Sefer T. <se...@ho...>]

Hi!

Oddly enough, I've been experiencing the same problem.
I'm using Linux Mandrake 9.1, which appears to come with a version of glibc 
2.3.2 (but I think this was happening with older glibc's as well).

I've written a tiny skeleton server that pre-creates a few threads 
(successfully) and then enters a poll loop (from which point the threads are 
not getting any cpu time at all).

It seems that there is some pthreads/poll issue, but this may also be 
related that I'm running everything on a laptop and we have already noticed 
that there might be some scheduling problems because TSC register being used 
is variable-rate on machines with power management active.

Thanks,
    Sefer.


>That's very strange.  V has threading problems with glibcs > 2.3.1,
>though.  So I wonder if that's it.  Do you have an older linux
>distro you can try it on, something like RH 7.3, or Suse 8.1 ?
>Basically anything with glibc 2.3.1 or before; 2.2.5 would be
>even better.

>J

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: [Valgrind-users] not understanding some valgrind errors against afs...

[Sebastian K. <Seb...@so...>]

From: "Jeremy Fitzhardinge" <je...@go...>
> Thinking about it, I quite like Sebastian's idea of a
> VALGRIND_STACK_SWITCH(thresh) call.  This would mean "when you see a %esp
> movement of at least threah bytes, that's a stack switch".  This would be
a
> trigger thing, in that once the motion has been seen, future %esp changes
are
> seen as being within one stack until another call to
VALGRIND_STACK_SWITCH.
>
> Note that if stacks are closely spaced, thresh would be considerably
smaller than
> the stack size (since going from a full stack adjacent empty stack just
below
> would be an %esp movement of less than a stack size - it could be
arbitarily
> small).

Oh, thats the problem. But then, if we're already at placing hints in the
source, then maybe another one:
VALGRIND_REGISTER_STACK(adr, size) -- this would inform Valgrind that
particular memory area is possibly going to become a separate stack at some
time in the future. This would also work as invalidator for stack allocated
from heap. To make stuff easier nagative value of size would mean that area
is below (not above) adr, which could be sometimes more natural approach
work stacks growing downwards.
Then add VALGRIND_UNREGISTER_STACK(adr).

rgds
Sebastian Kaliszewski


>
> J
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>

Re: [Valgrind-users] hardcoded /usr/bin/gdb

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

On Fri, 18 Apr 2003, Olly Betts wrote:

> > AC_PATH_PROG(GDB, gdb)
> > AC_DEFINE(GDB_PATH, @GDB@, "gdb path")
> > AC_SUBST(GDB)
> >
> > doesn't work cause configure don't do subsititution in
> > config.h.in when creating config.h, I don't think there is
> > any way to put it in config.h.in.
>
> There is - just use this:
>
> AC_PATH_PROG(GDB, gdb)
> AC_DEFINE_UNQUOTED(GDB_PATH, "$GDB", "gdb with path")

Ah, perfect, just what I wanted.  I just committed the change.  Thanks.

N

Re: [Valgrind-users] hardcoded /usr/bin/gdb

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

On Wed, Apr 16, 2003 at 07:00:05PM +0000, Philippe Elie wrote:
> Yes, it's a better way but the trivial:
> 
> AC_PATH_PROG(GDB, gdb)
> AC_DEFINE(GDB_PATH, @GDB@, "gdb path")
> AC_SUBST(GDB)
> 
> doesn't work cause configure don't do subsititution in
> config.h.in when creating config.h, I don't think there is
> any way to put it in config.h.in.

There is - just use this:

AC_PATH_PROG(GDB, gdb)
AC_DEFINE_UNQUOTED(GDB_PATH, "$GDB", "gdb with path")

Note that you must use AC_DEFINE_UNQUOTED instead of AC_DEFINE to get
$GDB expanded before it is substituted - otherwise config.h will
contain:

#define GDB_PATH "$GDB"

Cheers,
    Olly

Re: [Valgrind-users] not understanding some valgrind errors against afs...

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

Quoting Josef Weidendorfer <Jos...@in...>:

> On Thursday 17 April 2003 10:31, Jeremy Fitzhardinge wrote:
> > ...
> > I think the correct solution is to move stack switch detection into
> the
> > skin themselves (memcheck, addrcheck and helgrind are the only ones I
> know
> > of which care).  Memcheck and addrcheck can use their existing
> validity
> > info to make the determination; helgrind is harder.
> 
> Calltree does ESP tracking, too. Needed for recursion detection and
> correct 
> handling of setjmp/longjmp or C++ exceptions and like that.
> 
> So I'm voting for a skin trackable event for stack switching from the
> core. 
> Isn't this almost the same as the "switch_thread" event?
> As I see, the first stack switch always has quite a large delta. If we

switch_thread is a clear event which the scheduler knows about.  A change of 
value in %esp can mean one of two things, and there's no way of really telling 
what it means without some heuristics.  The heuristics we have at present get it 
wrong too often, with very bad results.

> Doesn't the kernel need to know about stack segments somehow by
> declaring the 
> VMA as growable? So isn't it enough to check for ESP changes among
> growable 
> VMAs?
> Or how behaves the LWP lib of AFS on stack overflows? If it uses
> mprotect() 
> for manual stack growing, we can track this, too.

The kernel only grows the main stack, not thread stacks; thread stacks are 
generally never growable. 

Thinking about it, I quite like Sebastian's idea of a 
VALGRIND_STACK_SWITCH(thresh) call.  This would mean "when you see a %esp 
movement of at least threah bytes, that's a stack switch".  This would be a 
trigger thing, in that once the motion has been seen, future %esp changes are 
seen as being within one stack until another call to VALGRIND_STACK_SWITCH. 

Note that if stacks are closely spaced, thresh would be considerably smaller than 
the stack size (since going from a full stack adjacent empty stack just below 
would be an %esp movement of less than a stack size - it could be arbitarily 
small).

	J

RE: [Valgrind-users] not understanding some valgrind errors against afs...

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

Quoting Nicholas Nethercote <nj...@ca...>:
> Maybe have VALGRIND_START_STACK_SWITCH and VALGRIND_END_STACK_SWITCH,
> and
> within that look for a "sizeable" %esp change (eg. anything bigger
> than
> 1KB or something) as a genuine switch?  Or maybe not, I don't know.

Tricky if the context switch is performed by an instruction which both changes 
%esp and %eip (ie, leave).  There would be no way to place the "after" 
annotation.

> 
> > I think the correct solution is to move stack switch detection into
> the skin
> > themselves (memcheck, addrcheck and helgrind are the only ones I know
> of which
> > care).  Memcheck and addrcheck can use their existing validity info to
> make the
> > determination; helgrind is harder.
> 
> How does validity info help?

Basically, if you're extending the stack over some already-valid memory, it means 
you're switching to a new stack at a lower address (since the valid memory is one 
or more intermediate stacks, or some other allocated memory); if you're shrinking 
the stack over some already-invalid memory, you're actually switching to a stack 
with a higher address.

The only case where I can think of this failing is if your current stack has 
another stack just above it which has grown to touch/overlap this stack, and you 
context switch to it.  But if that has happened, you've already got into deep 
trouble.

Hm, now that I think about it, it doesn't really work that well when the stacks 
are in heap memory.  But then, how well does V cope with that anyway?  Wouldn't 
it allow access below %esp?

	J

Re: [Valgrind-users] valgrind / pthreads issue

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

That's very strange.  V has threading problems with glibcs > 2.3.1,
though.  So I wonder if that's it.  Do you have an older linux
distro you can try it on, something like RH 7.3, or Suse 8.1 ?
Basically anything with glibc 2.3.1 or before; 2.2.5 would be
even better.

J


On Thursday 17 April 2003 6:58 pm, Todd Richmond wrote:
> I just started using valgrind and it has already found 2 nasty buffer
> overruns for me. However, it only works on my single threaded programs. I
> have a MT server that uses a thread pool for incoming socket requests - one
> thread poll()s on all fds and then queues up work objects to be run by
> slave threads. My problem is that once the master thread is started, it
> runs properly in a poll() loop (with a few second timeout), but other
> threads receive almost no cpu time, including the original main thread that
> started the master poller! At first I thought all other threads were hung
> indefinitely, but I left the program run for 30+ minutes and the main
> thread finally printed out a debug string after the pthread_create() so
> slowly that it did so one character at a time over several minutes.
>
> I am using Redhat 8 updated to all current patches which includes glibc
> 2.3.2 and have tried both vgrind 1.9.5 and the 2.0 cvs branch
>
> Thanks,
>     Todd
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users

[Valgrind-users] valgrind / pthreads issue

[Todd R. <ric...@pr...>]

I just started using valgrind and it has already found 2 nasty buffer
overruns for me. However, it only works on my single threaded programs. I
have a MT server that uses a thread pool for incoming socket requests - one
thread poll()s on all fds and then queues up work objects to be run by slave
threads. My problem is that once the master thread is started, it runs
properly in a poll() loop (with a few second timeout), but other threads
receive almost no cpu time, including the original main thread that started
the master poller! At first I thought all other threads were hung
indefinitely, but I left the program run for 30+ minutes and the main thread
finally printed out a debug string after the pthread_create() so slowly that
it did so one character at a time over several minutes.

I am using Redhat 8 updated to all current patches which includes glibc
2.3.2 and have tried both vgrind 1.9.5 and the 2.0 cvs branch

Thanks,
    Todd

[Valgrind-users] Re: SSE instruction?

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

* Mathieu Malaterre -- Thursday 17 April 2003 16:03:
> If you are using the lastest nvidia driver you can use:
> 
> $__GL_FORCE_GENERIC_CPU=1 valgrind ...

Or else you can still override the nvidia driver by mesa, as in

  $ LD_PRELOAD=/usr/lib/GL/libGL.so.1.3.mesasoft valgrind ...

m.

Re: [Valgrind-users] SSE instruction?

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

On Thu, 17 Apr 2003, Jos van den Oever wrote:

> Now I'm rather clueless about SSE, but I know 3DNow is Athlon specific.
> Is SSE Pentium related? Or is MMX not completely implemented yet?

SSE and SSE2 are yet more sets of extra instructions, like MMX and 3DNow.
They are supported by modern Pentiums and Athlons.  Valgrind doesn't yet
support them.

However, NVidia also noticed this it seems, and the "latest" drivers
(version 4349, apparently) come with this text

        DISABLING CPU SPECIFIC FEATURES

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

Set __GL_FORCE_GENERIC_CPU=1 and Valgrind should work.

N

Re: [Valgrind-users] SSE instruction?

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

If you are using the lastest nvidia driver you can use:

$__GL_FORCE_GENERIC_CPU=1 valgrind ...

mathieu

Jos van den Oever wrote:
> I'm trying to debug an OpenGL program on a Pentium IV with an NVidia 
> Riva TNT2 graphics card. However valgrind from today's CVS on SuSE 8.2 
> gives me this error:
> 
> disInstr: unhandled 2-byte opcode: 0x28 0x2 0xF
> This _might_ be the result of executing a SSE, SSE2 or 3DNow!
> instruction.  Valgrind does not currently support such instructions.  
> Sorry.
> Aborted
> 
> Now I'm rather clueless about SSE, but I know 3DNow is Athlon specific. 
> Is SSE Pentium related? Or is MMX not completely implemented yet?
> 
> Best regards, Jos van den Oever
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-users mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
> 


-- 
Mathieu Malaterre
CREATIS
28 Avenue du Doyen LEPINE
B.P. Lyon-Montchat
69394 Lyon Cedex 03
http://www.creatis.insa-lyon.fr/~malaterre/

Re: [Valgrind-users] not understanding some valgrind errors against afs...

[Thomas R. T. <tr...@cs...>]

valgrind seems to have a problem with swapcontext() tasking.
We use getcontext/setcontext/swapcontext
rather than setjmp/longjmp for tasking.
The *context routines are slower than *jmp
but seem to be a more official API for tasking.

For example the program below triggers messages such as:
==26015== Invalid write of size 4
==26015==    at 0x42045D6C: __swapcontext (in /lib/i686/libc-2.2.93.so)
==26015==    Address 0xBFFFE9BC is on thread 1's stack

This isn't a problem for us, since we can optionally use pthread tasking.
But I thought I should mention it.

Tom Truscott

#include <stdio.h>
#include <stdlib.h>
#include <ucontext.h>

ucontext_t  child, parent;

#define STACKSZ (256*1024)

void childfunc(void)
{
   printf("entering child\n");

   swapcontext(&child, &parent);

   printf("leaving child\n");
}

int
main()
{
   printf("entering main\n");

   getcontext(&child);
   child.uc_link = 0;
   child.uc_stack.ss_sp = malloc(STACKSZ);
   child.uc_stack.ss_size = STACKSZ;
   child.uc_stack.ss_flags = 0;
   makecontext(&child, (void(*)())childfunc, 0);

   swapcontext(&parent, &child);

   printf("leaving main\n");

   return 0;
}

[Valgrind-users] SSE instruction?

[Jos v. d. O. <jos...@wu...>]

I'm trying to debug an OpenGL program on a Pentium IV with an NVidia 
Riva TNT2 graphics card. However valgrind from today's CVS on SuSE 8.2 
gives me this error:

disInstr: unhandled 2-byte opcode: 0x28 0x2 0xF
This _might_ be the result of executing a SSE, SSE2 or 3DNow!
instruction.  Valgrind does not currently support such instructions.  Sorry.
Aborted

Now I'm rather clueless about SSE, but I know 3DNow is Athlon specific. 
Is SSE Pentium related? Or is MMX not completely implemented yet?

Best regards, Jos van den Oever

RE: [Valgrind-users] not understanding some valgrind errors against afs...

[Neulinger, N. <nn...@um...>]

> Or how behaves the LWP lib of AFS on stack overflows? If it=20
> uses mprotect()=20
> for manual stack growing, we can track this, too.

I'm pretty sure it behaves really badly. The stack switching I believe
is fairly limited, and is being used to implement threads. The
application is responsible for requesting a large enough stack to handle
it's deepest nesting of calls. Since it's a server, and fairly
predictable, that isn't usually a problem.

-- Nathan

Re: [Valgrind-users] not understanding some valgrind errors against afs...

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

On Thursday 17 April 2003 10:31, Jeremy Fitzhardinge wrote:
> ...
> I think the correct solution is to move stack switch detection into the
> skin themselves (memcheck, addrcheck and helgrind are the only ones I know
> of which care).  Memcheck and addrcheck can use their existing validity
> info to make the determination; helgrind is harder.

Calltree does ESP tracking, too. Needed for recursion detection and correct 
handling of setjmp/longjmp or C++ exceptions and like that.

So I'm voting for a skin trackable event for stack switching from the core. 
Isn't this almost the same as the "switch_thread" event?
As I see, the first stack switch always has quite a large delta. If we 
remember the instruction address somehow and assume further stack switches if 
the same instruction is executed (breaking up a BB into two at this point).

[This is new in the resend to Valgrind-users]

Another idea:
Doesn't the kernel need to know about stack segments somehow by declaring the 
VMA as growable? So isn't it enough to check for ESP changes among growable 
VMAs?
Or how behaves the LWP lib of AFS on stack overflows? If it uses mprotect() 
for manual stack growing, we can track this, too.

Josef

Re: [Valgrind-users] not understanding some valgrind errors against afs...

[Sebastian K. <Seb...@so...>]

From: "Nicholas Nethercote" <nj...@ca...>
> Maybe have VALGRIND_START_STACK_SWITCH and VALGRIND_END_STACK_SWITCH, and
> within that look for a "sizeable" %esp change (eg. anything bigger than
> 1KB or something) as a genuine switch?  Or maybe not, I don't know.

Hello!
Just some not-insider suggestion:

Maybe then use VALGRING_START_STACK_SWITCH(min_size)?
min_size would be used to determine if ESP change is sizeable?

rgds
Sebastian Kaliszewski

RE: [Valgrind-users] not understanding some valgrind errors against afs...

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

On Thu, 17 Apr 2003, Jeremy Fitzhardinge wrote:

> > Would a client request be a good compromise?  Eg.  insert
> > VALGRIND_STACK_SWITCH just before the stack switch?  It's more
> > intrusive than a command line option, but it's more precise.  Similar
> > to the client request for handling self-modifying code.
> >
> > [I haven't thought through how the request would actually be
> > implemented, but it shouldn't be too hard, I think...]
>
> Yeah, it would.  It would need to mean something like "the next change to %esp is
> a stack switch", but what if changing the stack changes %esp multiple times?  How
> do you know if the compiler is going to generate some non-stack switch changes to
> %esp as part of its codegen?

Maybe have VALGRIND_START_STACK_SWITCH and VALGRIND_END_STACK_SWITCH, and
within that look for a "sizeable" %esp change (eg. anything bigger than
1KB or something) as a genuine switch?  Or maybe not, I don't know.


> I think the correct solution is to move stack switch detection into the skin
> themselves (memcheck, addrcheck and helgrind are the only ones I know of which
> care).  Memcheck and addrcheck can use their existing validity info to make the
> determination; helgrind is harder.

How does validity info help?

N

RE: [Valgrind-users] not understanding some valgrind errors against afs...

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

Quoting Robert Walsh <rj...@du...>:
> JeremyF and I had a chat about this over lunch a few weeks ago.  One
> idea floated was to check what the instruction that was ultimately
> responsible for the stack switch was.  If it was a move to sp type
> instruction, it's probably a stack switch.  Otherwise it's probably a
> push or a pop. 

No, if its a move, its probably a longjmp; you still can't tell whether its a 
stack switch or a longjmp within the stack.

	J

RE: [Valgrind-users] not understanding some valgrind errors against afs...

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

Quoting Nicholas Nethercote <nj...@ca...>:

> On Tue, 15 Apr 2003, Neulinger, Nathan wrote:
> 
> > I think (from what I understand) that the problem is that if you
> lower
> > the threshold to something like 128K, valgrind will get confused if
> you
> > allocate a 128K+ object on the stack. If you're certain that no
> > individual object on the stack would be that size, it would probably
> be
> > useful to have an option to specify it.
> 
> Would a client request be a good compromise?  Eg.  insert
> VALGRIND_STACK_SWITCH just before the stack switch?  It's more
> intrusive
> than a command line option, but it's more precise.  Similar to the
> client
> request for handling self-modifying code.
> 
> [I haven't thought through how the request would actually be
> implemented,
>  but it shouldn't be too hard, I think...]

Yeah, it would.  It would need to mean something like "the next change to %esp is 
a stack switch", but what if changing the stack changes %esp multiple times?  How 
do you know if the compiler is going to generate some non-stack switch changes to 
%esp as part of its codegen?

I think the correct solution is to move stack switch detection into the skin 
themselves (memcheck, addrcheck and helgrind are the only ones I know of which 
care).  Memcheck and addrcheck can use their existing validity info to make the 
determination; helgrind is harder.

	J

Re: [Valgrind-users] Strange behaviour with both 1.9.x and 1.0.x

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

Quoting Sebastian <sc...@nb...>:

> This code looks correct to me. 'rand_fd' leads to /dev/urandom, so to
> valgrind it should just look like if 'tmp' is defined by the read(), and
> the
> return value defined by the modulo operation.

Only if you're sure that max is defined.  Try scattering some 
VALGRIND_CHECK_DEFINED()s around to see what is actually a defined value where.

BTW, this won't generate an even distribution from 0...max if that's what you 
need.

    J

RE: [Valgrind-users] not understanding some valgrind errors against afs...

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

Quoting "Neulinger, Nathan" <nn...@um...>:

> I believe that LWP (afs's light weight process library) defaults to a
> minimum stack size of 192k for linux.
> 
> Although some of the users of that library request smaller -
> 8k/16k/24k/etc. I believe the minimum is enforced.
> 
> Here's the warnings I get when testing:
> 
> ==11883== Warning: client switching stacks?  %esp: 0xBFFFEB5C -->
> 0x41067ABC
> ==11883== Warning: client switching stacks?  %esp: 0x41067A08 -->
> 0xBFFFEB90
> ==11883== Warning: client switching stacks?  %esp: 0xBFFFEB8C -->
> 0x410AC094
> ==11883== Warning: client switching stacks?  %esp: 0x410ABE90 -->
> 0xBFFFEBC0
> ==11883== Warning: client switching stacks?  %esp: 0xBFFFE66C -->
> 0x410ABEF4
> 
> Those are fairly large address changes. It looks to me like it is
> switching to a temporary stack stored in malloc'd memory.
> 
> In vg_memory, it talks about a VG_PLAUSIBLE_STACK_SIZE of 8000000 and
> VG_HUGE_DELTA of VG_P_S_S / 4. 
> 
> I wonder if perhaps the issue is that the above stack switches show up
> as changes because it's going from the normal stack to malloc'd mem,
> but
> changes between the fake stacks are not showing up, since they are
> small
> switches within malloced mem. 

Yup, that would be it.  Make HUGE_DELTA smallish and see if that helps (and 
increase the LWP stack size if you can).

    J

Re: [Valgrind-users] hardcoded /usr/bin/gdb

[Philippe E. <ph...@wa...>]

Nicholas Nethercote wrote:
> On Wed, 16 Apr 2003, Philippe Elie wrote:
> 
> 
>>>This works, but it would be better if the GDB variable was put into a .h
>>>file, so it's available everywhere -- that's better than having to feed it
>>>in to every file that needs it with -D.  This could be done by introducing
>>>eg. vg_skin.h.in, but that would be a pain, especially just for one
>>>variable.
>>
>>Yes, it's a better way but the trivial:
> 
> 
> [snip]
> 
> 
>>Not very elegant but the only way I found
> 
> 
> Hmm, pretty ugly... if that's the only way to do it, I can live with
> passing in the option using -D :)

But the dependencies problem ?

If the flags change you don't recompile the right
file. A user with two gdb version, can change $PATH
to select a different version and run configure; make
but he will not get the right gdb version.


regard,
Phil

Re: [Valgrind-users] hardcoded /usr/bin/gdb

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

On Wed, 16 Apr 2003, Philippe Elie wrote:

> > This works, but it would be better if the GDB variable was put into a .h
> > file, so it's available everywhere -- that's better than having to feed it
> > in to every file that needs it with -D.  This could be done by introducing
> > eg. vg_skin.h.in, but that would be a pain, especially just for one
> > variable.
>
> Yes, it's a better way but the trivial:

[snip]

> Not very elegant but the only way I found

Hmm, pretty ugly... if that's the only way to do it, I can live with
passing in the option using -D :)

Thanks very much.

N