After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 663381 - g_thread_new_internal() doesn't copy name
g_thread_new_internal() doesn't copy name
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: gthread
2.31.x
Other Linux
: Normal major
: ---
Assigned To: gtkdev
gtkdev
Depends on:
Blocks:
 
 
Reported: 2011-11-04 07:05 UTC by Milan Crha
Modified: 2011-11-15 03:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Milan Crha 2011-11-04 07:05:52 UTC 
Apart of all broken API on the master I noticed that g_thread_new_internal() doesn't copy the passed-in 'name' into the structure. There is no guarantee that the string will be a static string, neither a single note it's required. To be safe you should g_strdup it.
Comment 1 Matthias Clasen 2011-11-04 11:19:26 UTC 
Have you seen a problem due to this ?

The thread_name gets passed down into the kernel before g_thread_new returns, so there is really very little point in making a copy.
Comment 2 Milan Crha 2011-11-07 08:08:20 UTC 
Nope, just by code reading, when seeing [1], which is suspicious enough to believe that the 'name' pointer can be freed immediately after finish of g_thread_new call, before kernel gets to its content. I do not see in the code where the 'name' gets passed anywhere after [1].

[1] http://git.gnome.org/browse/glib/tree/glib/gthread.c#n889
Comment 3 Matthias Clasen 2011-11-07 18:16:59 UTC 
You may be right that the g_system_thread_set_name needs to be moved after the lock/unlock in the proxy function, at least.