|
From: Duncan S. <bal...@fr...> - 2005-08-01 12:31:55
|
I've noticed that I need to use smc-check=all, rather than smc-check=stack, when running a multithreaded program that uses trampolines. Presumably valgrind hasn't understood that the new thread's stack is a stack. Is this the intended behaviour? All the best, Duncan. |
|
From: Julian S. <js...@ac...> - 2005-08-01 12:39:13
|
> I've noticed that I need to use smc-check=all, rather than > smc-check=stack, when running a multithreaded program that > uses trampolines. Presumably valgrind hasn't understood > that the new thread's stack is a stack. Is this the > intended behaviour? No, certainly not. It sounds like a bug in the is-this-a-stack? department. Can you send a binary I can try? J |
|
From: Duncan S. <bal...@fr...> - 2005-08-01 14:46:52
|
> > I've noticed that I need to use smc-check=all, rather than > > smc-check=stack, when running a multithreaded program that > > uses trampolines. Presumably valgrind hasn't understood > > that the new thread's stack is a stack. Is this the > > intended behaviour? > > No, certainly not. It sounds like a bug in the is-this-a-stack? > department. Can you send a binary I can try? I've been trying to produce a small test case, but no luck so far. I'll keep trying, but if I fail I'll have to send you the 6 meg monster program plus supporting files weighing in at an extra 0.5M or so. Is that OK with you? All the best, Duncan. |
|
From: Julian S. <js...@ac...> - 2005-08-01 17:21:37
|
On Monday 01 August 2005 15:46, Duncan Sands wrote: > > > I've noticed that I need to use smc-check=all, rather than > > > smc-check=stack, when running a multithreaded program that > > > uses trampolines. Presumably valgrind hasn't understood > > > that the new thread's stack is a stack. Is this the > > > intended behaviour? > > > > No, certainly not. It sounds like a bug in the is-this-a-stack? > > department. Can you send a binary I can try? The cause of this is that with --smc-check=stack (the default) V does self-checking translations for code taken from segments which have the SF_GROWDOWN flag set. Unfortunately that appears to be only the initial thread at least on NPTL, and not the child stack threads. (Tom/Jeremy, is that indeed the case with NPTL?) My proposed fix (which I just tried and it works) is to instead do a self-checking translation if the segment from which the translation is to be taken is the same one into which the requesting thread's simulated stack pointer points. If you see what I mean. Does anyone see anything that could go disastrously wrong as a result? J |
|
From: Tom H. <to...@co...> - 2005-08-01 17:39:01
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
> The cause of this is that with --smc-check=stack (the default)
> V does self-checking translations for code taken from segments
> which have the SF_GROWDOWN flag set. Unfortunately that appears
> to be only the initial thread at least on NPTL, and not the child
> stack threads. (Tom/Jeremy, is that indeed the case with NPTL?)
Only the main stack is ever automatically extended. I believe that
is true for both linuxthreads and NPTL threads.
You should be looking at the SF_STACK flag I think.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Julian S. <js...@ac...> - 2005-08-01 22:28:09
|
> Only the main stack is ever automatically extended. I believe that > is true for both linuxthreads and NPTL threads. > > You should be looking at the SF_STACK flag I think. Alas .. only the main stack is marked SF_STACK, afaics. In order that V could know that the thread stacks are really stacks, it would have to be able to differentiate the mmap that creates them from arbitrary other anonymous mmaps that happen, and I don't think those stack-creating mmaps have any special flags that would distinguish them. So I don't think this _could_ work. It does however beg the question of what SF_STACK is really for. J |
|
From: Tom H. <to...@co...> - 2005-08-01 23:15:36
|
In message <200...@ac...>
Julian Seward <js...@ac...> wrote:
>
> > Only the main stack is ever automatically extended. I believe that
> > is true for both linuxthreads and NPTL threads.
> >
> > You should be looking at the SF_STACK flag I think.
>
> Alas .. only the main stack is marked SF_STACK, afaics. In order
> that V could know that the thread stacks are really stacks, it
> would have to be able to differentiate the mmap that creates
> them from arbitrary other anonymous mmaps that happen, and I don't
> think those stack-creating mmaps have any special flags that would
> distinguish them. So I don't think this _could_ work. It does
> however beg the question of what SF_STACK is really for.
Hmm. You're right... I could have sworn they all had SF_STACK set. In
fact in 2.2.0 they did, but it got lost with the threading changes.
The problem is that it is libpthread that allocates the stack now. We
could set SF_STACK on the segment if do_clone manages to find it.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-01 22:43:01
|
On Mon, 1 Aug 2005, Julian Seward wrote: > It does however beg the question of what SF_STACK is really for. It's used in the leak checker when deciding which segments should serve as roots. N ps: http://en.wikipedia.org/wiki/Begging_the_question |
|
From: Tom H. <to...@co...> - 2005-08-01 23:16:09
|
In message <Pin...@ch...>
Nicholas Nethercote <nj...@cs...> wrote:
> On Mon, 1 Aug 2005, Julian Seward wrote:
>
> > It does however beg the question of what SF_STACK is really for.
>
> It's used in the leak checker when deciding which segments should serve as
> roots.
Also a bug then presumably if only the first thread has it set...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Nicholas N. <nj...@cs...> - 2005-08-01 23:27:08
|
On Tue, 2 Aug 2005, Tom Hughes wrote: >> It's used in the leak checker when deciding which segments should serve as >> roots. > > Also a bug then presumably if only the first thread has it set... yep N |
|
From: Julian S. <js...@ac...> - 2005-08-01 23:28:51
|
> > It's used in the leak checker when deciding which segments should serve > > as roots. > > Also a bug then presumably if only the first thread has it set... Yup. Anyway: Duncan: I just committed my hacky fix (r4303). Can you update and check it? J |
|
From: Duncan S. <bal...@fr...> - 2005-08-02 07:37:56
|
Hi Julian, > Anyway: Duncan: I just committed my hacky fix (r4303). Can you > update and check it? while it fixes the test program I sent you, it fails badly on the monster program: with smc-check=stack, it fails to spot smc on the stack of the environment task (i.e. the process running the program, rather than a thread created later). I'll try to cook up a small test case. It's a bit strange because (1) single threaded programs seem to be OK; and (2) when I tweaked my multithreaded test program to also do trampolines on the environment task's stack, it went fine. Ciao, Duncan. |
|
From: Julian S. <js...@ac...> - 2005-08-02 07:58:05
|
> > Anyway: Duncan: I just committed my hacky fix (r4303). Can you > > update and check it? > > while it fixes the test program I sent you, it fails badly on the > monster program: with smc-check=stack, it fails to spot smc on the > stack of the environment task (i.e. the process running the program, > rather than a thread created later). It also fails the single-threaded regression test on my amd64 machine under obscure circumstances. I'll have a look shortly. J |
|
From: Julian S. <js...@ac...> - 2005-08-02 13:36:16
|
On Tuesday 02 August 2005 08:37, Duncan Sands wrote: > Hi Julian, > > > Anyway: Duncan: I just committed my hacky fix (r4303). Can you > > update and check it? Big sigh (horrible hack) Can you try r4305 and see if that helps? J |
|
From: Duncan S. <bal...@fr...> - 2005-08-02 14:22:58
|
> Can you try r4305 and see if that helps? Yes, it seems to do the job. Thanks a lot, Duncan. |