Date: Thu, 27 Jun 2002 15:12:57 +0200 (CEST) From: cejkar@fit.vutbr.cz To: FreeBSD-gnats-submit@FreeBSD.org Subject: bin/39922: [PATCH?] Threaded applications executed with closed std file descr. could not use redirections Message-ID: <200206271312.g5RDCvL98013@kazi.fit.vutbr.cz>
next in thread | raw e-mail | index | archive | help
>Number: 39922
>Category: bin
>Synopsis: [PATCH?] Threaded applications executed with closed std file descr. could not use redirections
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: freebsd-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Jun 27 06:20:03 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator: Rudolf Cejka
>Release: FreeBSD 4.6-STABLE i386
>Organization:
FIT, Brno University of Technology, Czech Republic
>Environment:
Tested on 4.6-STABLE.
>Description:
When an threaded application (linked with libc_r) is executed
with closed some of the standard file descriptors (for example
some daemons, server processes...), initialization code of
threads opens two internal file descriptors (_thread_kern_pipe[0, 1])
that are then blocked for use by the threaded application, so if
one of _thread_kern_pipe[0, 1] gets value 0, 1, or 2, an
application could not use particular redirections. Similar scenario
can occur around fork()/close() combination of calls. I have found
this problem because of use of popen() library call in an
threaded application, where the situation is even worse, because
the failure of stdin/stdout redirection is silently ignored
(another bug???), so everything looked that works, but
communication between child and parent process was silently broken.
(I understand that it is possible to disable linking label_tape
with libc_r in my particular situation and problem should be
avoided, however I see that this problem can be easily triggered
by any real threaded applications.)
>How-To-Repeat:
>Fix:
Here are two patches, which maybe are not very perfect solution
to this problem, but they enable to run afbackup-3.3.7 with
media changer and threads enabled successfully on my system
via cron. The patches redirect descriptors _thread_kern_pipe[0, 1]
with too small value (< 3) to any bigger value.
--- uthread_init.c.orig Wed Jun 26 22:04:12 2002
+++ uthread_init.c Thu Jun 27 13:37:45 2002
@@ -111,6 +111,7 @@
_thread_init(void)
{
int fd;
+ int dupfd;
int flags;
int i;
size_t len;
@@ -207,6 +208,18 @@
else if ((_thread_kern_sched_stack = malloc(SCHED_STACK_SIZE)) == NULL)
PANIC("Failed to allocate stack for scheduler");
else {
+ if (_thread_kern_pipe[0] < 3 &&
+ (dupfd = _thread_sys_fcntl(_thread_kern_pipe[0],
+ F_DUPFD, 3)) != -1) {
+ close(_thread_kern_pipe[0]);
+ _thread_kern_pipe[0] = dupfd;
+ }
+ if (_thread_kern_pipe[1] < 3 &&
+ (dupfd = _thread_sys_fcntl(_thread_kern_pipe[1],
+ F_DUPFD, 3)) != -1) {
+ close(_thread_kern_pipe[1]);
+ _thread_kern_pipe[1] = dupfd;
+ }
/* Zero the global kernel thread structure: */
memset(&_thread_kern_thread, 0, sizeof(struct pthread));
_thread_kern_thread.flags = PTHREAD_FLAGS_PRIVATE;
--- uthread_fork.c.orig Wed Jun 26 22:04:09 2002
+++ uthread_fork.c Thu Jun 27 13:37:45 2002
@@ -43,6 +43,7 @@
pid_t
_fork(void)
{
+ int dupfd;
int i, flags;
pid_t ret;
pthread_t pthread;
@@ -109,6 +110,18 @@
/* Abort this application: */
PANIC("Cannot initialize priority ready queue.");
} else {
+ if (_thread_kern_pipe[0] < 3 &&
+ (dupfd = _thread_sys_fcntl(_thread_kern_pipe[0],
+ F_DUPFD, 3)) != -1) {
+ close(_thread_kern_pipe[0]);
+ _thread_kern_pipe[0] = dupfd;
+ }
+ if (_thread_kern_pipe[1] < 3 &&
+ (dupfd = _thread_sys_fcntl(_thread_kern_pipe[1],
+ F_DUPFD, 3)) != -1) {
+ close(_thread_kern_pipe[1]);
+ _thread_kern_pipe[1] = dupfd;
+ }
/*
* Enter a loop to remove all threads other than
* the running thread from the thread list:
>Release-Note:
>Audit-Trail:
>Unformatted:
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-bugs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200206271312.g5RDCvL98013>