develooper Front page | perl.perl5.porters | Postings from July 2009

Re: [perl #63886] 5.8.9 binary incompatibility: PL_perlio_mutex not initialized

Thread Previous | Thread Next
From:
Craig A. Berry
Date:
July 19, 2009 16:33
Subject:
Re: [perl #63886] 5.8.9 binary incompatibility: PL_perlio_mutex not initialized
Message ID:
c9ab31fc0907191633y2185ef9bnec7e4d75baf9b5bc@mail.gmail.com
On Sat, Mar 14, 2009 at 6:31 PM, Edward Moy<perlbug-followup@perl.org> wrote:
> # New Ticket Created by  Edward Moy
> # Please include the string:  [perl #63886]
> # in the subject line of all future correspondence about this issue.
> # <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=63886 >


> However, for embedded code compiled before 5.8.9, PERL_SYS_INIT3 was a
> macro that defined the initialization directly (no call to Perl_sys_init3(),
> which didn't exist), but without PERLIO_INIT, which wasn't defined before
> 5.8.9. Since PerlIO_init() now doesn't initialize either, PL_perlio_mutex is
> left uninitialized, and this causes the crash and premature exit noted above.
>
> The workaround is to reinstate the PL_perlio_mutex initialization in
> PerlIO_init(), but this means that MUTEX_INIT(&PL_perlio_mutex) may be
> called twice in some cases.  However, the crash/exit is avoided.  Here is the
> patch

The problem with that approach is that the standard at
www.opengroup.org for pthread_mutex_init says, "Attempting to
initialise an already initialised mutex results in undefined
behaviour."  So I don't know that we should risk initializing the
mutex twice, at least as a general. cross-platform solution.

If I understand the report, the problem is when an embedded
application compiled using headers from Perl 5.8.8 or before tries to
use a libperl from a 5.8.9 Perl -- is that correct?  Does recompiling
the application from scratch against 5.8.9 (or, for that matter
5.10.x) solve the problem?  While that  shouldn't be necessary (and is
obviously bad if it is), it does help isolate this as a binary
compatibility problem in the 5.8.x branch only.

Since PERL_SYS_INIT and friends were converted to functions before the
release of 5.10.0:

http://perl5.git.perl.org/perl.git/commit/cbec8eb

I don't believe we'll see the same problem in the 5.10.x branch.  If
new initializations get added at some point, they can be added to the
functions, and any embedder will call the same functions after an
upgrade but just get the new initializations as well.

For 5.8.x there are two problems.  One is that PerlIO_init() would
have to be able to detect either whether it was being called from an
embedder built against 5.8.8 or earlier, or whether the mutex had not
already been initialized.  Only under those circumstances should it
attempt to initialize the mutex as in the proposed patch.  But the
bigger problem is that resources and general interest in producing
additional 5.8.x releases are pretty slim, so likely there will never
be a 5.8.10.

If I've misunderstood anything (and especially if there are
implications for 5.10.1), please speak up.

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About