Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 22 Oct 2001 08:54:58 EEST
From:      Maxim Sobolev <sobomax@FreeBSD.org>
To:        deischen@FreeBSD.org, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Cc:        gnome@FreeBSD.org
Subject:   Re: cvs commit: src/lib/libc_r/uthread uthread_fd.c
Message-ID:  <200110220554.IAA49045@ipcard.iptcom.net>
In-Reply-To: <200110211823.f9LINo559434@freefall.freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Oct 2001 11:23:50 -0700 (PDT), Daniel Eischen wrote:
> deischen    2001/10/21 11:23:50 PDT
> 
>   Modified files:
>     lib/libc_r/uthread   uthread_fd.c 
>   Log:
>   In the words of the submitter:
>   
>     In libc_r, if _FDLOCKS_ENABLED is not defined, there is no guarantee
>     in many of the sycall wrappers that _thread_fd_table[fd] is
>     initialized.  This causes problems for programs that pass in file
>     descriptors and execve() another program; when the exec'ed program
>     tries to do an fcntl() or other syscall on the passed-in fd, it fails.
>   
>   Add calls to initialize the FD table entry for _thread_fd_lock and
>   _thread_fd_lock_debug.

This reminds me of another strange problem I'm seeing in the
pthread-linked programs on the 5-CURRENT, where the program
in question uses pipes to communicate with a child spawn via
a fork(2). For some reason child's copy of _thread_fd_table[fd]
gets corrupted, so subsequent syscall on the pipe fd's causes
a segfault. I've also observed the same crash pattern in some
pthread-linked apps that use our popen(3) routine, in this
case fcntl(2) call in the popen(3) is causing a segfault. I
donno if it counts, but usually this involves a relatively high
fd number - 11. Unfortunately my attempt to provide a small
showcase failed, the problem usually manifests itself only in
the rather complex programs, which makes debugging difficult.

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.

-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?200110220554.IAA49045>