[issues] Re: Regression cause by patch PR nptl/3270

[Daniel Jacobowitz <dan@xxxxxxxxxxxxxxxx>]

On Sun, May 10, 2009 at 02:39:22PM +0200, Aurelien Jarno wrote:
> Hi,
> 
> EGLIBC has a patch to fix PR nptl/3270, unfortunately, it breaks 
> libgnomevfs, causing iceweasel or epiphany to hang in certain 
> conditions. Here is the corresponding changelog:
> 
> 2008-02-23  Daniel Jacobowitz  <dan@xxxxxxxxxxxxxxxx>
> 
> 	PR nptl/3270
> 	nptl/
> 	* allocatestack.c (setxid_mark_thread, setxid_unmark_thread): New.
> 	(setxid_signal_thread): Return a successful signal indicator.  Just
> 	skip threads without SETXID_BITMASK.
> 	(__nptl_setxid): Use separate marking and unmarking loops.  Repeat
> 	signalling if necessary.
> 	* init.c (sighandler_setxid): Use atomic operations for
> 	cancelhandling.  Wake __nptl_setxid last.

It's sad that libgnomevfs needs this functionality.  While POSIX does
define set*id in multi-threaded programs, they're inherently
inefficient (at least on Linux).  As you can see from my patch,
they are essentially a barrier across all threads.

> And here is the backtrace I get:
> 
> | Program received signal SIGINT, Interrupt.
> | [Switching to Thread 0x7f6f657127f0 (LWP 25103)]
> | __nptl_setxid (cmdp=0x7fff6d845f60) at allocatestack.c:1038
> | 1038    allocatestack.c: No such file or directory.
> |         in allocatestack.c
> | (gdb) bt
> | #0  __nptl_setxid (cmdp=0x7fff6d845f60) at allocatestack.c:1038
> | #1  0x00007f6f60c5c7db in *__GI_seteuid (uid=<value optimized out>)
> |     at ../sysdeps/unix/sysv/linux/seteuid.c:44
> | #2  0x00007f6f5e28bce0 in ?? () from /usr/lib/libgnomevfs-2.so.0
> | #3  0x00007f6f5e28be6e in gnome_vfs_transform_get () from /usr/lib/libgnomevfs-2.so.0
> | #4  0x00007f6f5e299e2a in gnome_vfs_uri_new_private () from /usr/lib/libgnomevfs-2.so.0
> | #5  0x00007f6f5e294c54 in gnome_vfs_monitor_add () from /usr/lib/libgnomevfs-2.so.0
> | #6  0x00007f6f5e28fb56 in ?? () from /usr/lib/libgnomevfs-2.so.0
> 
> Any idea what can be wrong in this patch?

Not from this, sorry.  The first thing to check would be where other
threads are.  We're trying to make sure that every thread switches;
the racy cases are threads being created or deleted while the
operation is in progress.

-- 
Daniel Jacobowitz
CodeSourcery