Date: Mon, 22 Oct 2001 15:38:16 +0300 From: Maxim Sobolev <sobomax@FreeBSD.org> To: Alfred Perlstein <bright@mu.org> Cc: deischen@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, gnome@FreeBSD.org Subject: Re: cvs commit: src/lib/libc_r/uthread uthread_fd.c Message-ID: <3BD41338.C4252B7C@FreeBSD.org> References: <200110211823.f9LINo559434@freefall.freebsd.org> <200110220554.IAA49045@ipcard.iptcom.net> <20011022010626.G15052@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein wrote: > > * Maxim Sobolev <sobomax@FreeBSD.org> [011022 00:55] wrote: > > > > This causes many big GNOME programs not work on 5-CURRENT > > because GNOME's Object Activation Framework is actively using > > fd's passed to a fork'ed copy. Perhaps you have any ideas on > > how to debug this problem, please let me know if so. > > Hmm, if fd's are being passed, are they being passed using > sendmsg/recvmsg? If so you might want to check if libc_r > catches this and properly initializes the fd array. It seems that I did not properly explain the problem. The programs in question usually create a pipe via a pipe(2) syscall, then spawn a child and use one end of that pipe in the parent and second one in the child for communication. For some strange reason, when program is linked with -pthread, the child's copy of _thread_fd_table[fd] sometimes gets corrupted around high fd numbers (11 and more), so when the child passes a fd of its end of the pipe to any syscall it leads to a segfault (usually a null-pointer derefernce). I'm ready to provide a stack trace if somebody is interested. -Maxim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3BD41338.C4252B7C>