Front page | perl.perl5.porters |
Postings from July 2009
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