Hide Forgot
Description of problem: pthread_setname_np silently fails if strlen(name) > 15. Version-Release number of selected component (if applicable): glibc-2.12-1.107.el6_4.5.x86_64 How reproducible: always Steps to Reproduce: Compile and run attached test case Actual results: pthread_setname_np returns with 0 Expected results: pthread_setname_np returns with != 0 and errno set to ERANGE like described in the man page Additional info: Happenens also on glibc 2.17 A constant in glibc describing the maximum allowed length would be nice. Thanks, Gregor
Created attachment 824167 [details] Test case
(In reply to Gregor Jasny from comment #0) > Description of problem: > pthread_setname_np silently fails if strlen(name) > 15. > > Version-Release number of selected component (if applicable): > glibc-2.12-1.107.el6_4.5.x86_64 > > How reproducible: > always > > Steps to Reproduce: > Compile and run attached test case > > Actual results: > pthread_setname_np returns with 0 > > Expected results: > pthread_setname_np returns with != 0 and errno set to ERANGE like described > in the man page > > Additional info: > Happenens also on glibc 2.17 > A constant in glibc describing the maximum allowed length would be nice. Your test case for pthread_setname_np is invalid, and your expectations are also not correct. Please allow me to try to explain. The POSIX thread APIs are desgined not to set errno. Therefore you can't use perror to print errors for the POSIX thread API functions, you must explicitly check the return values for non-zero errors like ERANGE. Your checks are for "if (i < 0)" which is also incorrect, you must explicitly check for "i != 0" followed by explicit checks for "i == ERANGE" and handle the error as required. Your expectations are therefore not correct, while the return is non-zero the return itself is ERANGE and those values may ore may not be negative or positive (in the case of GNU/Linux they are positive). For any other information please see the manual pages for pthread_setname_np. The maximum allowable length of the program name is a kernel constant called TASK_COMM_LEN and is not exported to userspace. It is tricky to expose this to userspace since it would forever limit pthread_setname_np, but I understand that without knowing the constant you can't know how small a name is supported by the kernel. Perhaps the best way forward is to use a sysconf() call to determine this value. Does that answer your question?
Thank you for this kind explanation. Please close this bug.
I added several test cases for pthread_[sg]etname_np upstream to ensure that this works consistently and correctly for linux. commit 1db94db157ed6c9e233178c9f3d21be46a1d181e Author: Carlos O'Donell <carlos> Date: Thu Dec 12 00:44:29 2013 -0500 Add test case for pthread_[sg]etname_np. This commit adds a testcase for pthread_setname_np and pthread_getname_np. The testcase itself has four tests to validate that these functions work as expected. The test is only enabled for Linux since it requires access to an alternate method for validating the functions work.