bin/50770: popen in libc_r not threadsafe

Georg Graf georg at graf.priv.at
Thu Apr 10 01:50:09 PDT 2003


>Number:         50770
>Category:       bin
>Synopsis:       popen in libc_r not threadsafe
>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 Apr 10 01:50:07 PDT 2003
>Closed-Date:
>Last-Modified:
>Originator:     Georg Graf
>Release:        FreeBSD 4.7-RELEASE-p7 i386
>Organization:
WU WIEN
>Environment:
System: FreeBSD schurli.wu-wien.ac.at 4.7-RELEASE-p7 FreeBSD
4.7-RELEASE-p7 #0: Tue Mar 4 07:47:12 CET 2003
root at mingus.wu-wien.ac.at:/usr/obj/usr/src/sys/GENERIC i386

System: FreeBSD milo.wu-wien.ac.at 4.8-RELEASE FreeBSD 4.8-RELEASE #0:
Wed Apr 2 18:22:23 CEST 2003
root at milo.wu-wien.ac.at:/usr/obj/usr/src/sys/GENERIC i386

System: FreeBSD philip.wu-wien.ac.at 5.0-RELEASE FreeBSD 5.0-RELEASE #0:
Wed Apr 9 14:30:35 CEST 2003
root at philip.wu-wien.ac.at:/usr/obj/usr/src/sys/PHILIP i386

>Description:
Using popen(3) from within a thread causes weird behavior after running
the program for a while. I assume that the pipe creation code in popen
and the pipe deletion code in pclose should be made reentrant in libc_r.

Some of the created childs stay hanging in a fcntl loop before doing the
exec, as shown in http://schurli.wu-wien.ac.at/pthread/pr. And in the
parent process the pclose(3) call in some threads constantly fails with
EAGAIN.

Note also that this program may crash a 4.7-RELEASE-p8 (not exactly sure
about the patchlevel) SMP machine. Should I file an extra PR for that?

>How-To-Repeat:
Basically: Call popen() and pclose() in a program compiled with
-pthread, and do not protect these calls with a mutex.

I have haunted this bug on  http://schurli.wu-wien.ac.at/pthread.tgz
"co -r1.32 thread.c" gives a version where you can see the described
behavior.

>Fix:
The workaround: protect the popen and pclose calls with a mutex, so that
the operations on filedescriptors in the global scope are atomic. (As
done in -r1.33 of my program). IMO for a fix this should be moved into
the library.

Please contact me if you want me to propose a fix for that.

Thank you!

>Release-Note:
>Audit-Trail:
>Unformatted:


More information about the freebsd-bugs mailing list