|
From: Bart V. A. <bar...@gm...> - 2006-12-23 12:48:27
|
Apparently it is not yet clear why I proposed to add the capability of
associating names with threads to Valgrind's core, so I will try to
explain this via the following example:
$ VALGRIND_LIB=.in_place coregrind/valgrind --tool=memcheck
memcheck/tests/stack_switch
==7764== Memcheck, a memory error detector.
==7764== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==7764== Using LibVEX rev 1680, a library for dynamic binary translation.
==7764== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==7764== Using valgrind-3.3.0.SVN, a dynamic binary instrumentation framework.
==7764== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==7764== For more details, rerun with: -v
==7764==
==7764== Syscall param clone(child_tidptr) contains uninitialised byte(s)
==7764== at 0x4110648: clone (in /lib/libc-2.4.so)
==7764== by 0x406887B: (below main) (in /lib/libc-2.4.so)
==7764==
==7764== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 3 from 1)
==7764== malloc/free: in use at exit: 0 bytes in 0 blocks.
==7764== malloc/free: 0 allocs, 0 frees, 0 bytes allocated.
==7764== For counts of detected errors, rerun with: -v
==7764== All heap blocks were freed -- no leaks are possible.
In the output above memcheck prints one error report. How is a user
supposed to find out which thread the error report applies to ? My
opinion is that Valgrind should print some information that allows to
identify the thread unambiguously, such that thread ID's printed by
the client can be correlated with thread ID's printed by Valgrind.
This information could be one of the following:
- Process ID. A process ID only identifies a thread when using
linuxthreads, not when using NPTL or when using another OS than Linux.
- POSIX thread ID. POSIX thread ID's are currently not known by
Valgrinds core however.
- lwpid. It is not very convenient however to obtain this ID from
within a client -- a client either would have to call
readlink("/proc/self") or would have to call gettid() via inline
assembly (gettid() is not in glibc).
- Thread name, where thread names are stored in Valgrind's core and
provided by the client via a client request.
Thread ID's can e.g. be printed from within m_errormgr.c:
--- m_errormgr.c (revision 6413)
+++ m_errormgr.c (working copy)
@@ -628,6 +628,11 @@
n_errs_found++;
if (!is_first_shown_context)
VG_(message)(Vg_UserMsg, "");
+ else
+ {
+ VG_(message)(Vg_UserMsg, "thread context: %s",
+ VG_(get_thread_name)(VG_(get_running_tid())));
+ }
pp_Error(p);
is_first_shown_context = False;
n_errs_shown++;
What is your opinion about this ?
Bart.
|
|
From: Nicholas N. <nj...@cs...> - 2006-12-23 23:58:59
|
On Sat, 23 Dec 2006, Bart Van Assche wrote:
> Apparently it is not yet clear why I proposed to add the capability of
> associating names with threads to Valgrind's core, so I will try to
> explain this via the following example:
> [...]
> In the output above memcheck prints one error report. How is a user
> supposed to find out which thread the error report applies to ? My
> opinion is that Valgrind should print some information that allows to
> identify the thread unambiguously, such that thread ID's printed by
> the client can be correlated with thread ID's printed by Valgrind.
> This information could be one of the following:
> - Process ID. A process ID only identifies a thread when using
> linuxthreads, not when using NPTL or when using another OS than Linux.
> - POSIX thread ID. POSIX thread ID's are currently not known by
> Valgrinds core however.
> - lwpid. It is not very convenient however to obtain this ID from
> within a client -- a client either would have to call
> readlink("/proc/self") or would have to call gettid() via inline
> assembly (gettid() is not in glibc).
Some error messages already print a thread ID, eg. "address X is on thread
1's stack" -- which of these three does it correspond to?
> - Thread name, where thread names are stored in Valgrind's core and
> provided by the client via a client request.
>
> What is your opinion about this ?
I think allowing thread naming is a good idea.
Nick
|
|
From: Nicholas N. <nj...@cs...> - 2006-12-24 00:02:50
|
On Sun, 24 Dec 2006, Nicholas Nethercote wrote: >> What is your opinion about this ? > > I think allowing thread naming is a good idea. I forgot to add: one difficulty is that it involves changing Memcheck's error messages, and several tools (eg. GUI front-ends) take those messages as input, in text or XML form. However, there may be some other changes to Memcheck's error messages in 3.3.0 anyway, so maybe it's not a big deal. N |
|
From: Bart V. A. <bar...@gm...> - 2006-12-24 09:35:35
|
On 12/24/06, Nicholas Nethercote <nj...@cs...> wrote: > > Some error messages already print a thread ID, eg. "address X is on thread > 1's stack" -- which of these three does it correspond to? As far as I know only memcheck prints this kind of messages, and memcheck then prints Valgrind's thread ID's (ThreadId, I did not even mention these in my list). These are ID's that are not known by the client, and hence which are hard to correlate to thread ID's printed by the client. Bart. |
|
From: Julian S. <js...@ac...> - 2006-12-24 14:20:47
|
> I think allowing thread naming is a good idea. Yes, me too. Seems like a small but helpful thing that the core can offer to thread-related tools. J |