|
From: Augusto V. <aug...@si...> - 2005-08-02 19:25:58
|
Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> I've noticed some strange behavior getting the current tid in a tool I'm building.<br> <br> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> I've some C helpers, which are called from instrumentation code. Inside helpers, I call VG_(get_running_tid), which always return thread ids between 1 and 3 (never mind how many pthreads the client program had).<br> <br> I thought it was some problem with VG_(get_running_tid), so I registered (in my tool) a callback function to be notified (from core) on thread switchings. But, the same problem occurs.<br> <br> I think that (valgrind) threads could be merged into (kernel) threads.... but I'm not sure about this (kernel threads are transparent to Valgrind, isn't it?)<br> <br> All help will be wellcome.<br> <br> Augusto<br> <meta name="Generator" content="Kate, the KDE Advanced Text Editor"> <br> <br> <br> <br> </body> </html> |
|
From: Tom H. <to...@co...> - 2005-08-02 21:04:58
|
In message <42E...@si...>
Augusto Vega <aug...@si...> wrote:
> <body bgcolor="#ffffff" text="#000000">
> I've noticed some strange behavior getting the current tid in a tool
> I'm building.<br>
Plain text would be appreciated...
> I've some C helpers, which are called from instrumentation code. Inside
> helpers, I call VG_(get_running_tid), which always return thread ids
> between 1 and 3 (never mind how many pthreads the client program had).
What version of valgrind are we alking about here?
> I thought it was some problem with VG_(get_running_tid), so I
> registered (in my tool) a callback function to be notified (from core)
> on thread switchings. But, the same problem occurs.
If that's the thread_run event then note that it wasn't being called
in the valgrind 3 code until the other day.
> I think that (valgrind) threads could be merged into (kernel)
> threads.... but I'm not sure about this (kernel threads are transparent
> to Valgrind, isn't it?)
I think don't I understand this. What do mean by 'merging' the
threads exactly?
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Tom H. <to...@co...> - 2005-08-02 21:09:42
|
In message <b2e...@lo...>
Tom Hughes <to...@co...> wrote:
> In message <42E...@si...>
> Augusto Vega <aug...@si...> wrote:
>
> > I've some C helpers, which are called from instrumentation code. Inside
> > helpers, I call VG_(get_running_tid), which always return thread ids
> > between 1 and 3 (never mind how many pthreads the client program had).
>
> What version of valgrind are we alking about here?
>
> > I thought it was some problem with VG_(get_running_tid), so I
> > registered (in my tool) a callback function to be notified (from core)
> > on thread switchings. But, the same problem occurs.
>
> If that's the thread_run event then note that it wasn't being called
> in the valgrind 3 code until the other day.
I guess you must be talking about the 2.4.0 code though, as it
looks like VG_(get_running_tid) doesn't work in the 3.0 code at
the moment as it is part of the thread state modelling.
In fact even in 2.4.0 it may not be that reliable as the thread
state modelling wasn't complete or well tested.
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|
|
From: Augusto V. <aug...@si...> - 2005-08-02 21:34:01
|
Content-Transfer-Encoding: 7bit Thanks Tom. Actually, 2.4.0 is the Valgrind version I'm working on. I think I know what is happening (timing problem). Client pthreads finish too fast, so Valgrind reuse the entry in vg_threads[]. Which version has a complete and well-tested thread state modeling? I appreciate your help, Augusto Tom Hughes wrote: > In message <b2e...@lo...> > Tom Hughes <to...@co...> wrote: > > >>In message <42E...@si...> >> Augusto Vega <aug...@si...> wrote: >> >> >>>I've some C helpers, which are called from instrumentation code. Inside >>>helpers, I call VG_(get_running_tid), which always return thread ids >>>between 1 and 3 (never mind how many pthreads the client program had). >> >>What version of valgrind are we alking about here? >> >> >>>I thought it was some problem with VG_(get_running_tid), so I >>>registered (in my tool) a callback function to be notified (from core) >>>on thread switchings. But, the same problem occurs. >> >>If that's the thread_run event then note that it wasn't being called >>in the valgrind 3 code until the other day. > > > I guess you must be talking about the 2.4.0 code though, as it > looks like VG_(get_running_tid) doesn't work in the 3.0 code at > the moment as it is part of the thread state modelling. > > In fact even in 2.4.0 it may not be that reliable as the thread > state modelling wasn't complete or well tested. > > Tom > |
|
From: Tom H. <to...@co...> - 2005-08-02 22:06:31
|
In message <42E...@si...>
Augusto Vega <aug...@si...> wrote:
> Actually, 2.4.0 is the Valgrind version I'm working on.
> I think I know what is happening (timing problem). Client pthreads
> finish too fast, so Valgrind reuse the entry in vg_threads[].
Quite likely - you probably need to catch the post_thread_create
event so you can tell when an ID is being recycled.
> Which version has a complete and well-tested thread state modeling?
There isn't one I'm afraid.
That said it looks like that function is not part of the thread
modelling so I think you're alright. I was confusing the thread
state code and the thread model code...
Tom
--
Tom Hughes (to...@co...)
http://www.compton.nu/
|