[uClibc 0000972]: errno broken in linuxthreads.old

bugs at busybox.net bugs at busybox.net
Fri Oct 19 18:15:16 UTC 2007


A NOTE has been added to this issue. 
====================================================================== 
http://busybox.net/bugs/view.php?id=972 
====================================================================== 
Reported By:                bsfost
Assigned To:                uClibc
====================================================================== 
Project:                    uClibc
Issue ID:                   972
Category:                   Posix Threads
Reproducibility:            always
Severity:                   minor
Priority:                   normal
Status:                     assigned
====================================================================== 
Date Submitted:             07-27-2006 05:36 PDT
Last Modified:              10-19-2007 11:15 PDT
====================================================================== 
Summary:                    errno broken in linuxthreads.old
Description: 
I have a problem where, effectively, errno is never set in threads within
applications built with uClibc (using the linuxthreads.old library).
Debugging has shown that the system call (send(), in the case of the
example) is made and the global/libc errno is set prior to returning to
application code. The subsequent request to retrieve the error code calls
into __errno_location() in the linuxthreads.old library, which finds the
appropriate thread descriptor and returns (*self->p_errnop), which was
never set.

I didn't see anything obvious that "intended" to set the thread specific
errno value based on system calls made on that thread's behalf (i.e., I
would expect this in the syscall wrappers, perhaps..?), but I'm fairly new
to this library so I'm not sure whether this is considered a bug,
misconfiguration or simple lack of functionality. 

For completeness, I compared the behavior with an _old_ glibc-2.2 system
which looked like it had the same general design. The application worked
in this case, but I noticed that the thread_self() call (while requesting
the errno value in the thread, following the failed syscall) ended up
returning a pointer to the __pthread_initial_thread structure rather than
the specific thread structure I assume it created when it cloned (which is
what happens in uClibc's thread_self()). 

I also tested a quick change in uClibc by setting
__pthread_manager_thread's p_errnop to '&_errno' as well as new threads
created in pthread_handle_create(). This change allowed expected behavior,
but it's probably not the appropriate fix. Any information on this is
greatly appreciated, and let me know if I've been unclear or missed any
important points. Thanks.

Brian

====================================================================== 

---------------------------------------------------------------------- 
 andre_rosa - 08-23-07 17:19  
---------------------------------------------------------------------- 
The attached file has different behavior in mipsel platform when comparing
with glibc in a regular PC. 

---------------------------------------------------------------------- 
 corp186 - 10-19-07 11:15  
---------------------------------------------------------------------- 
This appears to be fixed by revision 15936. I have applied the diff from
15935 to 15936 to the sources I saw this bug with and it fixed the issue
for me. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
07-27-06 05:36  bsfost         New Issue                                    
07-27-06 05:36  bsfost         Status                   new => assigned     
07-27-06 05:36  bsfost         Assigned To               => uClibc          
08-23-07 17:11  andre_rosa     Issue Monitored: andre_rosa                    
08-23-07 17:18  andre_rosa     File Added: main3.c                          
08-23-07 17:19  andre_rosa     Note Added: 0002680                          
10-19-07 11:15  corp186        Note Added: 0002834                          
======================================================================




More information about the uClibc-cvs mailing list