Skip Menu |
 
Report information
Id: 34914
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: dmichelsen <dam [at] baltic-online.de>
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: low
Type: unknown
Perl Version: (no value)
Fixed In: (no value)



Subject: Possible filedescriptor race condition in 5.8.3 and 5.8.6
Date: Mon, 11 Apr 2005 17:57:58 +0200
To: perlbug [...] perl.org
From: "Dagobert Michelsen" <dam [...] baltic-online.de>
Download (untitled) / with headers
text/plain 1.1k
Hi, I am currently working with an embedded version of Perl 5.8.3 and 5.8.6 on Solaris together with OpenLDAP 2.2.23. Perl seems to have a race condition which mixes up filehandles from other threads. Perl was not compiled with thread support (neither 5.005 nor ithreads) as all accesses to the Perl instance have been serialized with mutexes. The problem arises when Perl issues a close followed by a dup2 onto the closed filehandle and another thread (unrelated to the Perl instance) opens the filehandle just closed prior to dup2ing to it. The problem has been analyzed by Howard Chu from the OpenLDAP team at http://www.openldap.org/its/index.cgi/Incoming?id=3567;selectid=3567;usearchives=1 and he suggested dropping the explicit close as dup2 already closes the target fd. As the code in the IO systems seems mighty fragile I would grately appreciate help removing this race condition. Best regards -- Dagobert Michelsen -- Dagobert Michelsen (Leiter IT) Baltic Online Computer GmbH Alter Markt 1-2, 24103 Kiel, +49 431 54003-0 (Fon) -99 (Fax) Flughafenstr. 52c, 22335 Hamburg, +49 40 53299-395 (Fon) -100 (Fax)
CC: bugs-bitbucket [...] netlabs.develooper.com, Dagobert Michelsen <dam [...] baltic-online.de>
Subject: Re: [perl #34914] Possible filedescriptor race condition in 5.8.3 and 5.8.6
Date: Mon, 11 Apr 2005 20:21:18 -0700
To: perl5-porters [...] perl.org
From: Gurusamy Sarathy <gsar [...] ActiveState.com>
Download (untitled) / with headers
text/plain 1.2k
On 11 Apr 2005 16:01:06 -0000, Dagobert Michelsen wrote: Show quoted text
[...] Show quoted text
>I am currently working with an embedded version of Perl 5.8.3 and >5.8.6 on Solaris together with OpenLDAP 2.2.23. > >Perl seems to have a race condition which mixes up filehandles >from other threads. Perl was not compiled with thread support >(neither 5.005 nor ithreads) as all accesses to the Perl instance >have been serialized with mutexes. The problem arises when Perl >issues a close followed by a dup2 onto the closed filehandle and >another thread (unrelated to the Perl instance) opens the filehandle >just closed prior to dup2ing to it. The problem has been analyzed >by Howard Chu from the OpenLDAP team at > http://www.openldap.org/its/index.cgi/Incoming?id=3567;selectid=3567;usearch >ives=1 >and he suggested dropping the explicit close as dup2 already >closes the target fd.
I remember fixing a problem similar to the one you've reported back in 2002. Perhaps the problem code has come back? http://public.activestate.com/cgi-bin/perlbrowse?patch=16331 This fix may also be relevant: http://public.activestate.com/cgi-bin/perlbrowse?patch=16333 HTH, Sarathy gsar@ActiveState.com
CC: ts [...] gebeco.de
Subject: Re: [perl #34914] Possible filedescriptor race condition in 5.8.3 and 5.8.6
Date: Tue, 12 Apr 2005 10:35:51 +0200
To: perlbug-followup [...] perl.org
From: "Dagobert Michelsen" <dam [...] baltic-online.de>
Hi, Von "Gurusamy Sarathy via RT" <perlbug-followup@perl.org> (12 Apr 2005 03:26:42 -0000): Show quoted text
> On 11 Apr 2005 16:01:06 -0000, Dagobert Michelsen wrote: > [...]
> >I am currently working with an embedded version of Perl 5.8.3 and > >5.8.6 on Solaris together with OpenLDAP 2.2.23. > > > >Perl seems to have a race condition which mixes up filehandles > >from other threads. Perl was not compiled with thread support > >(neither 5.005 nor ithreads) as all accesses to the Perl instance > >have been serialized with mutexes. The problem arises when Perl > >issues a close followed by a dup2 onto the closed filehandle and > >another thread (unrelated to the Perl instance) opens the filehandle > >just closed prior to dup2ing to it. The problem has been analyzed > >by Howard Chu from the OpenLDAP team at > > http://www.openldap.org/its/index.cgi/Incoming?id=3567;selectid=3567;usearch > >ives=1 > >and he suggested dropping the explicit close as dup2 already > >closes the target fd.
> > I remember fixing a problem similar to the one you've reported back in > 2002. Perhaps the problem code has come back? > > http://public.activestate.com/cgi-bin/perlbrowse?patch=16331 > > This fix may also be relevant: > > http://public.activestate.com/cgi-bin/perlbrowse?patch=16333
The code in 5.8.3 looks quite similar to your fix, however it only applies if Perl was compiled with threads or ithreads. To my understanding it is not necessary to compile Perl with thread support if Perl itself is not threaded, but is used in a single thread as embedded component (this is the scenario I am using). Do you see a disadvantage of applying your new code even if Perl is not compiled with thread-support? Why did you limit your code to a threaded environment? Best regards -- Dagobert -- Dagobert Michelsen (Leiter IT) Baltic Online Computer GmbH Alter Markt 1-2, 24103 Kiel, +49 431 54003-0 (Fon) -99 (Fax) Flughafenstr. 52c, 22335 Hamburg, +49 40 53299-395 (Fon) -100 (Fax)
CC: perlbug-followup [...] perl.org, ts [...] gebeco.de, perl5-porters [...] perl.org
Subject: Re: [perl #34914] Possible filedescriptor race condition in 5.8.3 and 5.8.6
Date: Tue, 12 Apr 2005 19:12:23 -0700
To: "Dagobert Michelsen" <dam [...] baltic-online.de>
From: Gurusamy Sarathy <gsar [...] ActiveState.com>
Download (untitled) / with headers
text/plain 3.2k
On Tue, 12 Apr 2005 10:35:51 +0200, "Dagobert Michelsen" wrote: Show quoted text
>Von "Gurusamy Sarathy via RT" <perlbug-followup@perl.org> (12 Apr 2005 03:26:4 >2 -0000):
>> I remember fixing a problem similar to the one you've reported back in >> 2002. Perhaps the problem code has come back? >> >> http://public.activestate.com/cgi-bin/perlbrowse?patch=16331 >> >> This fix may also be relevant: >> >> http://public.activestate.com/cgi-bin/perlbrowse?patch=16333
> >The code in 5.8.3 looks quite similar to your fix, however it >only applies if Perl was compiled with threads or ithreads. To >my understanding it is not necessary to compile Perl with thread >support if Perl itself is not threaded,
This is not correct. To be completely safe, you need to build libperl with threads support if you want to run even a single perl interpreter within a threaded program. Otherwise things like errno will not work right, since libperl might update a static copy of errno, while the rest of your program that is compiled with -D_REENTRANT or similar might do something else, like indirecting through __errno_location(). Another potential problem is all the foo()/foo_r() functions in libc and elsewhere that perl links with. I don't think you're guaranteed to get sane results if the same program calls both foo() and foo_r() functions from different threads. Still another problem is mixing malloc()s (either perl's or libc's) that was built with/without threads support. There are literally hundreds of other similar cases. It might be instructive to grep your libc headers for _REENTRANT (or whatever your libc calls it). Show quoted text
>but is used in a single >thread as embedded component (this is the scenario I am using). >Do you see a disadvantage of applying your new code even if >Perl is not compiled with thread-support? Why did you limit >your code to a threaded environment?
To be clear, change#16331 wasn't specific to USE_THREADS. change#16333 was made USE_THREADS specific because it relies on libc/stdio internals knowledge, and it doesn't make sense to add that onerous requirement to the vanilla perl binary (which does not run multi-threaded). It might be a good idea to add a separate #define for that code and enable it by default in USE_THREADS mode. People who want it can then enable it without USE_THREADS. However, if you're linking libperl into a threaded program and you didn't compile libperl with threads support, you're probably going to see other problems (as in the cases above). If you're not a perl internals whiz to know whether caveats like the above matter for your application, I highly recommend the simple and obvious fix: build your perl with -Duseithreads. Incidentally, I see this in 5.8.6's PerlIOStdio_invalidate_fileno(): #if 0 /* Sarathy's code did this - we fall back to a dup/dup2 hack (which isn't thread safe) instead */ # error "Don't know how to set FILE.fileno on your platform" #endif which means that platforms that don't have support in PerlIOStdio_invalidate_fileno() are silently getting a thread-unsafe perl when building with -Duseithreads. That seems very broken to me. How about disabling support for the "stdio" layer on such platforms when building with -Duseithreads? Sarathy gsar@ActiveState.com
Subject: Re: [perl #34914] Possible filedescriptor race condition in 5.8.3 and 5.8.6
Date: Wed, 13 Apr 2005 17:18:26 +0200
To: perlbug-followup [...] perl.org
From: "Dagobert Michelsen" <dam [...] baltic-online.de>
Download (untitled) / with headers
text/plain 14.4k

Message body is not shown because it is too large.

CC: ts [...] gebeco.de, perlbug-followup [...] perl.org, perl5-porters [...] perl.org,"Dagobert Michelsen" <dam [...] baltic-online.de>
Subject: Re: [perl #34914] Possible filedescriptor race condition in 5.8.3and 5.8.6
Date: Wed, 13 Apr 2005 22:04:16 +0100
To: gsar [...] ActiveState.com
From: Nick Ing-Simmons <nick [...] ing-simmons.net>
Download (untitled) / with headers
text/plain 833b
Gurusamy Sarathy <gsar@ActiveState.com> writes: Show quoted text
> >Incidentally, I see this in 5.8.6's PerlIOStdio_invalidate_fileno(): > > #if 0 > /* Sarathy's code did this - we fall back to a dup/dup2 hack > (which isn't thread safe) instead > */ > # error "Don't know how to set FILE.fileno on your platform" > #endif > >which means that platforms that don't have support in >PerlIOStdio_invalidate_fileno() are silently getting a thread-unsafe >perl when building with -Duseithreads. That seems very broken to me. >How about disabling support for the "stdio" layer on such platforms >when building with -Duseithreads?
Fine. :stdio has "inhertited" that code from pre-layered code. IIRC at the time I wrote that "such platforms" were: A. Linux B. Then-new Solaris C. Win32/Borland which were only ones I had ;-)


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org