Bug 322254

Summary:	Show threadname together with tid if set by application
Product:	[Developer tools] valgrind	Reporter:	Matthias Schwarzott <zzam>
Component:	general	Assignee:	Julian Seward <jseward>
Status:	RESOLVED FIXED
Severity:	normal	CC:	florian
Priority:	NOR
Version:	3.9.0.SVN
Target Milestone:	---
Platform:	Compiled Sources
OS:	Linux
Latest Commit:		Version Fixed In:
Attachments:	remember threadname and print it when printing tid remember threadname and print it when printing tid (also in xml output)

Description Matthias Schwarzott 2013-07-11 19:24:43 UTC

The attached patch makes each thread remember the threadname if the application set one.
This is done by intercepting the call to prctl(PR_SET_NAME, name).
The name is then remembered in struct ThreadState.
Then when printing a tid, I changed the code to also print the threadname. That makes error output and vgdb usage with lots of threads more funny.


Reproducible: Always

Comment 1 Matthias Schwarzott 2013-07-11 19:27:01 UTC

Created attachment 81064 [details]
remember threadname and print it when printing tid

Comment 2 Matthias Schwarzott 2013-07-11 19:28:45 UTC

The patch could be changed to make the default threadname be the same as argv[0] as for normal applications instead of being empty.
I would like to have a testcase for vgdb, but some output filter need to be modified for this.

Comment 3 Matthias Schwarzott 2013-09-13 06:54:47 UTC

Created attachment 82308 [details]
remember threadname and print it when printing tid (also in xml output)

Updated the patch to also write the threadname to xml output.
run testcase for text and xml output.

Comment 4 Matthias Schwarzott 2013-09-13 06:58:26 UTC

How should the xml changes be documented?

Comment 5 Florian Krohm 2013-09-16 17:13:03 UTC

Thanks for the patch. Quite useful. I applied it with some minor mods as r13553.. 

As for your question regarding the documentation of the XML, that is in 
docs/internal/xml-output-protocol4.txt. Yeah, we should probably have a DTD. Maybe some day...

Comment 6 Florian Krohm 2013-09-16 17:13:20 UTC

Closing now..

Comment 7 Matthias Schwarzott 2013-09-18 11:41:12 UTC

If a client does call pthread_setname_np (or directly prctrl) a second time to change the name, the first threadname is leaked.

See this output from outer/inner on modified threadname.c:
==3366== 16 bytes in 1 blocks are definitely lost in loss record 11 of 125
==3366==    at 0x2803E365: vgPlain_arena_malloc (m_mallocfree.c:1710)
==3366==    by 0x2803F29F: vgPlain_arena_strdup (m_mallocfree.c:2264)
==3366==    by 0x2809EA34: vgSysWrap_linux_sys_prctl_after (syswrap-linux.c:957)
==3366==    by 0x28089C57: vgPlain_post_syscall (syswrap-main.c:1784)
==3366==    by 0x2808A366: vgPlain_client_syscall (syswrap-main.c:1706)
==3366==    by 0x28086601: handle_syscall (scheduler.c:1068)
==3366==    by 0x28087E46: vgPlain_scheduler (scheduler.c:1346)
==3366==    by 0x2809A91E: run_a_thread_NORETURN (syswrap-linux.c:103)
==3366==    by 0x2809ACB0: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:304)
==3366==    by 0x280C5028: ??? (in /home/masc1329/work-hd/valgrind-inner.git/memcheck/memcheck-x86-linux)

Comment 8 Florian Krohm 2013-09-18 11:58:57 UTC

(In reply to comment #7)
> If a client does call pthread_setname_np (or directly prctrl) a second time
> to change the name, the first threadname is leaked.
> 

Yes, I have heard :)  WIll fix.

Comment 9 Florian Krohm 2013-09-18 14:00:36 UTC

(In reply to comment #8)
> (In reply to comment #7)
> > If a client does call pthread_setname_np (or directly prctrl) a second time
> > to change the name, the first threadname is leaked.
> > 
> 
> Yes, I have heard :)  WIll fix.

Done in 13561.