GNOME Bugzilla – Bug 60642
gnome-vfs assumes gethostbyname is thread-safe
Last modified: 2004-12-22 21:47:04 UTC
gnome_vfs_inet_connection_create calls gethostbyname(), which is not guaranteed to be thread-safe/reentrant. This makes programs that try to open multiple http/ftp/whatever connections in rapid succession hang on platforms where it's not. Linux and Solaris both define gethostbyname_r, but unfortunately they define it differently. The BSDs mostly seem not to define it. Yay. Anyway, evolution/e-util/e-host-utils.c sort of shows how to handle the various permutations, although it's really an awful interface and you probably don't want to just copy it. This applies to both gnome-vfs-1 and the trunk.
Thanks for pointing this out Dan. Are you actively running into this or is it a theoretical problem right now? (That should help us decide how important it is to fix this soon.)
The Evolution Summary component reliably gets stuck inside the guts of gethostbyname (doing a read when it needs to be doing a write) on NetBSD right now with an unpatched gnome-vfs. This is particularly a problem because the Summary is the default view when you start up, and there's no way to switch to another view if it's completely wedged like that. I don't know if the other BSDs are affected. Linux and Solaris seem not to be. BTW, since I posted this, I discovered that soup has a nicer abstraction for this than evolution does, in soup/src/libsoup/soup-socket-unix.c
Based on the comments in the evolution version of the function, it sounds like mixing more than one re-entrant gethostname wrapper still leads to potential problems if the system does not have gethostbyname_r; it seems like we can't fix this problem for good without getting a variant of this function for glib. In the meantime it sounds like a good idea to add a re-entrant gethostbyname wrapper based on the soup version.
Mass resetting target milestone to clean up gnome-vfs milestones. Please complain if I removed a milestone which should have been kept. Sorry for the spam
This is half-fixed in HEAD, in the sense that on every platform that has a known version of gethostbyname_r, it is used (linux glibc, solaris, hpux). It's still not fixed for the other platforms. Should there be a wrapper or not?
There is a G_LOCK for dns_lock for the other platforms. This doesn't address the problem mentioned in comment 3 (ie: multiple mutexes around this function is of no help) However, there is really nothing that can be done here. Application writers just need to avoid using unsafe gethostbyname() calls if they choose to use gnome-vfs.