5.8.9 binary incompatibility: PL_perlio_mutex not initialized

[p5pRT]

Migrated from rt.perl.org#63886 (status was 'resolved')

Searchable as RT63886$

[p5pRT]

From emoy@apple.com

Created by emoy@apple.com

On Mac OS X\, the Modo application by Luxology\, is a 3-D rendering
program that uses embedded perl. It works fine with perl 5.8.6 and 5.8.8\, but
with 5.8.9\, certain operations either cause the app to crash or exit while
in the perl interpreter. I have tracked this down to the PL_perlio_mutex
variable not being initialized.

What I believe was the cause is the change to PERL_SYS_INIT3 (and
PERL_SYS_INIT) to be defined as a function call (Perl_sys_init3() or Perl_sys_init()\, respectively). With this change Perl_sys_init3() and Perl_sys_init()
now call MUTEX_INIT(&PL_perlio_mutex) (via the PERLIO_INIT macro)\, instead of the function PerlIO_init() doing the initialization.

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 I used​:

===============================================================

Inline Patch

```diff --- perlio.c.orig 2008-10-29 00:36:47.000000000 -0700 +++ perlio.c 2009-03-14 16:08:38.000000000 -0700 @@ -2323,6 +2323,12 @@ { /* MUTEX_INIT(&PL_perlio_mutex) is done in PERL_SYS_INIT3(). */ PERL_UNUSED_CONTEXT; + /* + * No, for backwards compatibility (before PERL_SYS_INIT3 changed ```

to be + * defined as a separate function call)\, we need to call + * MUTEX_INIT(&PL_perlio_mutex) (via the PERLIO_INIT macro). + */ + PERLIO_INIT;   }

  void

Edward Moy Apple

Perl Info

``` Flags: category=core severity=high Site configuration information for perl v5.8.9: Configured by emoy at Sat Mar 14 11:36:05 PDT 2009. Summary of my perl5 (revision 5 version 8 subversion 9) configuration: Platform: osname=darwin, osvers=10.0, archname=darwin-thread-multi-2level uname='darwin boson.apple.com 10.0 darwin kernel version 10.0.0d6: sun mar 8 00:05:17 pst 2009; root:xnu-1396~1release_i386 i386 ' config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags= -Dman3ext=3pm -Duseithreads -Duseshrplib -Dinc_version_list=none - Dcc=gcc-4.2' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=define uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='gcc-4.2', ccflags ='-arch i386 -arch ppc -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include', optimize='-Os', cppflags='-g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='4.2.1 (Apple Inc. build 5641)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='gcc-4.2 -mmacosx-version-min=10.6', ldflags ='-arch i386 - arch ppc -L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lutil -lc perllibs=-ldl -lm -lutil -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-arch i386 -arch ppc -bundle - undefined dynamic_lookup -L/usr/local/lib' Locally applied patches: /Library/Perl/Updates/ comes before system perl directories installprivlib and installarchlib points to the Updates directory @INC for perl v5.8.9: /Volumes/XDisk/emoy/home/site_perl/darwin-thread-multi-2level /Volumes/XDisk/emoy/home/site_perl /System/Library/Perl/5.8.9/darwin-thread-multi-2level /System/Library/Perl/5.8.9 /Library/Perl/5.8.9/darwin-thread-multi-2level /Library/Perl/5.8.9 /Network/Library/Perl/5.8.9/darwin-thread-multi-2level /Network/Library/Perl/5.8.9 /Network/Library/Perl /System/Library/Perl/Extras/5.8.9/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.9 /Library/Perl/5.8.8 /Library/Perl/5.8.6 /Library/Perl/5.8.1 . Environment for perl v5.8.9: DYLD_LIBRARY_PATH (unset) HOME=/Volumes/XDisk/emoy/home LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=/Volumes/XDisk/emoy/home/bin:/usr/bin:/bin:/usr/local/sbin:/ usr/sbin:/sbin:/usr/local/bin:/Developer/Tools:/usr/X11/bin:. PERL5LIB=/Volumes/XDisk/emoy/home/site_perl PERL_BADLANG (unset) SHELL=/bin/tcsh ```

[p5pRT]

From @nwc10

Dave notes​:

5.8.9 broke (and maybe 5.10.0 too?) OP includes a patch (not yet applied)

[p5pRT]

@nwc10 - Status changed from 'new' to 'open'

[p5pRT]

From p5p@spam.wizbit.be

On Sat Mar 14 16​:30​:59 2009\, emoy wrote​:

----------------------------------------------------------------- [Please describe your issue here]

On Mac OS X\, the Modo application by Luxology\, is a 3-D rendering
program that uses embedded perl. It works fine with perl 5.8.6 and 5.8.8\, but
with 5.8.9\, certain operations either cause the app to crash or exit while
in the perl interpreter. I have tracked this down to the PL_perlio_mutex
variable not being initialized.

What I believe was the cause is the change to PERL_SYS_INIT3 (and
PERL_SYS_INIT) to be defined as a function call (Perl_sys_init3() or Perl_sys_init()\, respectively). With this change Perl_sys_init3() and Perl_sys_init()
now call MUTEX_INIT(&PL_perlio_mutex) (via the PERLIO_INIT macro)\, instead of the function PerlIO_init() doing the initialization.

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 I used​: [snip]

Hi\,

Do you also have a test case for this bug/crash/exit?

Best regards\,

Bram

[p5pRT]

From emoy@apple.com

On May 29\, 2009\, at 12​:56 PM\, Bram via RT wrote​:

On Sat Mar 14 16​:30​:59 2009\, emoy wrote​:

----------------------------------------------------------------- [Please describe your issue here]

On Mac OS X\, the Modo application by Luxology\, is a 3-D rendering program that uses embedded perl. It works fine with perl 5.8.6 and 5.8.8\, but with 5.8.9\, certain operations either cause the app to crash or exit while in the perl interpreter. I have tracked this down to the PL_perlio_mutex variable not being initialized.

What I believe was the cause is the change to PERL_SYS_INIT3 (and PERL_SYS_INIT) to be defined as a function call (Perl_sys_init3() or
Perl_sys_init()\, respectively). With this change Perl_sys_init3() and Perl_sys_init() now call MUTEX_INIT(&PL_perlio_mutex) (via the PERLIO_INIT macro)\, instead of the function PerlIO_init() doing the initialization.

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 I used​: [snip]

Hi\,

Do you also have a test case for this bug/crash/exit?

Best regards\,

Bram

Not that doesn't require a third-party application\, like Modo or
GPSPhotoLinker\, which I can't provide to you. Matthew Craig matt@​luxology.com   is the tech support guy at Luxology that I worked with. Perhaps he
can provide a Modo license to you for testing.

Ed

[p5pRT]

From @craigberry

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.

[p5pRT]

From emoy@apple.com

On Jul 19\, 2009\, at 4​:33 PM\, Craig A. Berry wrote​:

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.

Sorry\, I've been meaning to reply\, but kept getting interrupted.

I agree my workaround is not a general purpose solution. It was only
to fix an immediate need in Mac OS X (where reinitializing a mutex
before it is actually used\, is OK to do). And AFAIK\, it doesn't affect
5.10\, since PERL_SYS_INIT was only define that one way.

However\, if an embedded perl program using 5.8\, was complied against
the previous PERL_SYS_INIT\, it will not work properly when run against
a later perl 5.8 with the modified PERL_SYS_INIT\, because the mutex is
not being initialized at all (and because on OS X\, the proper initial
value of a mutex is *not* zero). So the issue is really for programs
(especially commercial and third party programs) that may not be able
to immediately rebuild with a later 5.8\, and risk being incompatible
with users running older 5.8 versions.

Not knowing the code\, I can't say if the following suggestion would
work\, but could you setup another flag that indicated whether the
mutex has been initialized\, and if not initial it and set the flag?

---

Edward Moy Apple

[p5pRT]

From @jandubois

On Wed\, 29 Jul 2009\, Edward Moy wrote​:

On Jul 19\, 2009\, at 4​:33 PM\, Craig A. Berry wrote​: [...]

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. [...] Not knowing the code\, I can't say if the following suggestion would work\, but could you setup another flag that indicated whether the mutex has been initialized\, and if not initial it and set the flag?

It is not clear to me what you want to achieve​: You cannot change 5.8.9 anymore; it has already been released. It sounds extremely unlikely that there ever will be a 5.8.10 that will include anything but the fixes for the most severe security vulnerabilities. And the problem does not exist in the 5.10.x branch.

So while your change _could_ be applied to the maint-5.8 branch\, it would require support from the corresponding pumpkin (not sure if there is any for 5.8.x)\, and it would still do you no good because you don't know if it will ever be part of a real release.

If you want to fix the issue in a Perl version for your own use\, then I would recommend that you just remove the PERLIO_INIT from the PERL_SYS_INIT_BODY macro and put it back into the body of the S_init_tls_and_interp() function in perl.c. That's essentially what I did for ActivePerl when I discovered this issue (unfortunately after the release of 5.8.9). Just search for PERLIO_INIT in here​:

  http​://downloads.activestate.com/ActivePerl/src/5.8/AP826_diff.txt

Cheers\, -Jan

[p5pRT]

From @jandubois

On Thu\, 30 Jul 2009\, Edward Moy wrote​:

On Jul 30\, 2009\, at 6​:38 PM\, Jan Dubois wrote​:

On Wed\, 29 Jul 2009\, Edward Moy wrote​:

On Jul 19\, 2009\, at 4​:33 PM\, Craig A. Berry wrote​: [...]

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. [...] Not knowing the code\, I can't say if the following suggestion would work\, but could you setup another flag that indicated whether the mutex has been initialized\, and if not initial it and set the flag?

It is not clear to me what you want to achieve​: You cannot change 5.8.9 anymore; it has already been released. It sounds extremely unlikely that there ever will be a 5.8.10 that will include anything but the fixes for the most severe security vulnerabilities. And the problem does not exist in the 5.10.x branch.

So while your change _could_ be applied to the maint-5.8 branch\, it would require support from the corresponding pumpkin (not sure if there is any for 5.8.x)\, and it would still do you no good because you don't know if it will ever be part of a real release.

If you want to fix the issue in a Perl version for your own use\, then I would recommend that you just remove the PERLIO_INIT from the PERL_SYS_INIT_BODY macro and put it back into the body of the S_init_tls_and_interp() function in perl.c. That's essentially what I did for ActivePerl when I discovered this issue (unfortunately after the release of 5.8.9). Just search for PERLIO_INIT in here​:

http​://downloads.activestate.com/ActivePerl/src/5.8/AP826_diff.txt

I was just being a good citizen and reporting a bug\, and the (imperfect) patch that I used to fix the problem. I was not aware of the plan for future 5.8 updates (or lack thereof).

Thank you very much for reporting the issue! I was not trying to criticize this in any way. I was just genuinely wondering\, after Craig already pointed out that the chances of 5.8.10 are rather slim\, what you wanted to achieve with the change you proposed in the response to Craig's message.

And I gave you the reference to the ActivePerl fix\, which also solves the problem and avoids initializing the mutex multiple times\, in case you were just looking for a fix for your own version of 5.8.9.

However\, I hope the message has gotten across that future updates to any release should not break compatibility in this way.

Oh\, absolutely! I do blame myself for not checking these issues early enough to be able to report them before the release. I did see the original change\, but somehow didn't notice that it was going into 5.8 as well. In general moving PERL_SYS_INIT to a function is a good move\, as it allows us to change the functionality of PERL_SYS_INIT in a maintenance release without breaking backwards compatibility in this way.

Cheers\, -Jan

PS​: It is not clear to me what should be done with this bug report now. I would support adding a fix along the lines of the ActivePerl build 826 change to the maint-5.8 branch\, just in case 5.8.10 ever does get released. But I'm not sure who would be in a position to approve such a checkin right now. And it is also not a change that would go into blead or maint-5.10 to be integrated back because it doesn't apply to those branches.

[p5pRT]

From emoy@apple.com

On Jul 30\, 2009\, at 6​:38 PM\, Jan Dubois wrote​:

On Wed\, 29 Jul 2009\, Edward Moy wrote​:

On Jul 19\, 2009\, at 4​:33 PM\, Craig A. Berry wrote​: [...]

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. [...] Not knowing the code\, I can't say if the following suggestion would work\, but could you setup another flag that indicated whether the mutex has been initialized\, and if not initial it and set the flag?

It is not clear to me what you want to achieve​: You cannot change
5.8.9 anymore; it has already been released. It sounds extremely unlikely that there ever will be a 5.8.10 that will include anything but the fixes for the most severe security vulnerabilities. And the problem does not exist in the 5.10.x branch.

So while your change _could_ be applied to the maint-5.8 branch\, it would require support from the corresponding pumpkin (not sure if
there is any for 5.8.x)\, and it would still do you no good because you don't know if it will ever be part of a real release.

If you want to fix the issue in a Perl version for your own use\, then I would recommend that you just remove the PERLIO_INIT from the PERL_SYS_INIT_BODY macro and put it back into the body of the S_init_tls_and_interp() function in perl.c. That's essentially what I did for ActivePerl when I discovered this issue (unfortunately after the release of 5.8.9). Just search for PERLIO_INIT in here​:

http​://downloads.activestate.com/ActivePerl/src/5.8/AP826_diff.txt

Cheers\, -Jan

I was just being a good citizen and reporting a bug\, and the
(imperfect) patch that I used to fix the problem. I was not aware of
the plan for future 5.8 updates (or lack thereof).

However\, I hope the message has gotten across that future updates to
any release should not break compatibility in this way.

---

Edward Moy Apple

[p5pRT]

From @demerphq

2009/7/31 Jan Dubois \jand@&#8203;activestate\.com​:

On Thu\, 30 Jul 2009\, Edward Moy wrote​:

On Jul 30\, 2009\, at 6​:38 PM\, Jan Dubois wrote​:

On Wed\, 29 Jul 2009\, Edward Moy wrote​:

On Jul 19\, 2009\, at 4​:33 PM\, Craig A. Berry wrote​: [...]

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. [...] Not knowing the code\, I can't say if the following suggestion would work\, but could you setup another flag that indicated whether the mutex has been initialized\, and if not initial it and set the flag?

It is not clear to me what you want to achieve​: You cannot change 5.8.9 anymore; it has already been released. It sounds extremely unlikely that there ever will be a 5.8.10 that will include anything but the fixes for the most severe security vulnerabilities. And the problem does not exist in the 5.10.x branch.

So while your change _could_ be applied to the maint-5.8 branch\, it would require support from the corresponding pumpkin (not sure if there is any for 5.8.x)\, and it would still do you no good because you don't know if it will ever be part of a real release.

If you want to fix the issue in a Perl version for your own use\, then I would recommend that you just remove the PERLIO_INIT from the PERL_SYS_INIT_BODY macro and put it back into the body of the S_init_tls_and_interp() function in perl.c.  That's essentially what I did for ActivePerl when I discovered this issue (unfortunately after the release of 5.8.9).  Just search for PERLIO_INIT in here​:

 http​://downloads.activestate.com/ActivePerl/src/5.8/AP826_diff.txt

I was just being a good citizen and reporting a bug\, and the (imperfect) patch that I used to fix the problem.  I was not aware of the plan for future 5.8 updates (or lack thereof).

Thank you very much for reporting the issue!  I was not trying to criticize this in any way.  I was just genuinely wondering\, after Craig already pointed out that the chances of 5.8.10 are rather slim\, what you wanted to achieve with the change you proposed in the response to Craig's message.

And I gave you the reference to the ActivePerl fix\, which also solves the problem and avoids initializing the mutex multiple times\, in case you were just looking for a fix for your own version of 5.8.9.

However\, I hope the message has gotten across that future updates to any release should not break compatibility in this way.

Oh\, absolutely!  I do blame myself for not checking these issues early enough to be able to report them before the release.  I did see the original change\, but somehow didn't notice that it was going into 5.8 as well.  In general moving PERL_SYS_INIT to a function is a good move\, as it allows us to change the functionality of PERL_SYS_INIT in a maintenance release without breaking backwards compatibility in this way.

Cheers\, -Jan

PS​: It is not clear to me what should be done with this bug report now. I would support adding a fix along the lines of the ActivePerl build 826 change to the maint-5.8 branch\, just in case 5.8.10 ever does get released. But I'm not sure who would be in a position to approve such a checkin right now. And it is also not a change that would go into blead or maint-5.10 to be integrated back because it doesn't apply to those branches.

Assuming there is a tag of the "last commit in 5.8" of some sort i dont see why you shouldnt add a commit there.

Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @nwc10

On Fri\, Jul 31\, 2009 at 08​:51​:47PM +0200\, demerphq wrote​:

2009/7/31 Jan Dubois \jand@&#8203;activestate\.com​:

PS​: It is not clear to me what should be done with this bug report now. I would support adding a fix along the lines of the ActivePerl build 826 change to the maint-5.8 branch\, just in case 5.8.10 ever does get released. But I'm not sure who would be in a position to approve such a checkin right now. And it is also not a change that would go into blead or maint-5.10 to be integrated back because it doesn't apply to those branches.

So\, yes\, that's the logical place to apply it.

I think the best thing to do now is to apply it\, as it's clearly a 5.8.9 regression (one of only 4 discovered so far\, I think)\, and therefore "serious"\, so that if anyone picks up the maint-5.8 branch to make a release\, this will be in it. (We've had a 5.005_04\, and there was talk of 5.005_05 and 5.6.3 from a couple of people within the past 12 months\, all of which would be little more than build fixes.)

Assuming there is a tag of the "last commit in 5.8" of some sort i dont see why you shouldnt add a commit there.

Well\, there's a maint-5.8 branch. That's not a tag\, but seems to fit what you describe.

Nicholas Clark

[p5pRT]

From @demerphq

2009/8/1 Nicholas Clark \nick@&#8203;ccl4\.org​:

On Fri\, Jul 31\, 2009 at 08​:51​:47PM +0200\, demerphq wrote​:

2009/7/31 Jan Dubois \jand@&#8203;activestate\.com​:

PS​: It is not clear to me what should be done with this bug report now. I would support adding a fix along the lines of the ActivePerl build 826 change to the maint-5.8 branch\, just in case 5.8.10 ever does get released. But I'm not sure who would be in a position to approve such a checkin right now. And it is also not a change that would go into blead or maint-5.10 to be integrated back because it doesn't apply to those branches.

So\, yes\, that's the logical place to apply it.

I think the best thing to do now is to apply it\, as it's clearly a 5.8.9 regression (one of only 4 discovered so far\, I think)\, and therefore "serious"\, so that if anyone picks up the maint-5.8 branch to make a release\, this will be in it. (We've had a 5.005_04\, and there was talk of 5.005_05 and 5.6.3 from a couple of people within the past 12 months\, all of which would be little more than build fixes.)

Assuming there is a tag of the "last commit in 5.8" of some sort i dont see why you shouldnt add a commit there.

Well\, there's a maint-5.8 branch. That's not a tag\, but seems to fit what you describe.

What i meant is that if the last "official" commit (as decided by you) in the branch is tagged then it cant hurt to add to the main-branch.

BTW\, whats with your mail client? Everybody else i reply to with the reply-to functions on gmail results in sane behaviour wheras your posts always a) leave you out of the cc/to list\, and b) adds everybody else\, including the person doing the replying in to the to list​:

From​: Nicholas Clark \nick@&#8203;ccl4\.org To​: demerphq \demerphq@&#8203;gmail\.com Cc​: Jan Dubois \jand@&#8203;activestate\.com\, Edward Moy \emoy@&#8203;apple\.com\,   "Craig A. Berry" \craig\.a\.berry@&#8203;gmail\.com\, perl5-porters@​perl.org\,   perlbug-followup@​perl.org Subject​: Re​: [perl #63886] 5.8.9 binary incompatibility​: PL_perlio_mutex not initialized Message-ID​: \20090801211936\.GD60303@&#8203;plum\.flirble\.org Mail-Followup-To​: demerphq \demerphq@&#8203;gmail\.com\,   Jan Dubois \jand@&#8203;activestate\.com\, Edward Moy \emoy@&#8203;apple\.com\,   "Craig A. Berry" \craig\.a\.berry@&#8203;gmail\.com\, perl5-porters@​perl.org\,   perlbug-followup@​perl.org

So why do you stick that Mail-Followup-To line in there? Is this gmail stupidity\, your emails client stupidity\, some kind of workaround of general email stupidity\, merely an example of the standard hatefulness of email clients or what?

cheers\, Yves

-- perl -Mre=debug -e "/just|another|perl|hacker/"

[p5pRT]

From @nwc10

On Sat\, Mar 14\, 2009 at 04​:31​:00PM -0700\, Edward Moy wrote​:

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 I used​:

=============================================================== --- perlio.c.orig 2008-10-29 00​:36​:47.000000000 -0700 +++ perlio.c 2009-03-14 16​:08​:38.000000000 -0700 @​@​ -2323\,6 +2323\,12 @​@​ { /* MUTEX_INIT(&PL_perlio_mutex) is done in PERL_SYS_INIT3(). */ PERL_UNUSED_CONTEXT; + /* + * No\, for backwards compatibility (before PERL_SYS_INIT3 changed
to be + * defined as a separate function call)\, we need to call + * MUTEX_INIT(&PL_perlio_mutex) (via the PERLIO_INIT macro). + */ + PERLIO_INIT;

I think that we can avoid the problem of initialising it twice by

* removing MUTEX_INIT from PERL_SYS_INIT3 (for 5.8.10 and later) * adding it back into perlio.c (roughly as above)   but adding check in perlio.c\, and not doing the initialisation if   PL_subversion == 9.   (That is\, we are a perl 5.8.10 or later libperl\, but we're being called   from a perl binary\, or binary embedding perl\, which was compiled against   5.8.9's headers\, and so uses 5.8.9's definition of PERL_SYS_INIT3\, which   has the MUTEX_INIT within it.

See http​://perl5.git.perl.org/perl.git/blob/maint-5.8​:/perlvars.h#l90

(this wasn't why I put them in\, but nice to see that they have other uses)

Nicholas Clark

[p5pRT]

From @nwc10

On Sat\, Aug 01\, 2009 at 11​:29​:06PM +0200\, demerphq wrote​:

2009/8/1 Nicholas Clark \nick@&#8203;ccl4\.org​:

On Fri\, Jul 31\, 2009 at 08​:51​:47PM +0200\, demerphq wrote​:

2009/7/31 Jan Dubois \jand@&#8203;activestate\.com​:

Assuming there is a tag of the "last commit in 5.8" of some sort i dont see why you shouldnt add a commit there.

Well\, there's a maint-5.8 branch. That's not a tag\, but seems to fit what you describe.

What i meant is that if the last "official" commit (as decided by you)

It's not *me*. I retired. :-) I believe it's Dave\, but he's got his hands full with 5.10.1 now\, and I'd guess 5.10.x for the foreseeable never-ending doom^W^Wfuture.

in the branch is tagged then it cant hurt to add to the main-branch.

BTW\, whats with your mail client? Everybody else i reply to with the reply-to functions on gmail results in sane behaviour wheras your posts always a) leave you out of the cc/to list\, and b) adds everybody else\, including the person doing the replying in to the to list​:

From​: Nicholas Clark \nick@&#8203;ccl4\.org To​: demerphq \demerphq@&#8203;gmail\.com Cc​: Jan Dubois \jand@&#8203;activestate\.com\, Edward Moy \emoy@&#8203;apple\.com\, "Craig A. Berry" \craig\.a\.berry@&#8203;gmail\.com\, perl5-porters@​perl.org\, perlbug-followup@​perl.org Subject​: Re​: [perl #63886] 5.8.9 binary incompatibility​: PL_perlio_mutex not initialized Message-ID​: \20090801211936\.GD60303@&#8203;plum\.flirble\.org Mail-Followup-To​: demerphq \demerphq@&#8203;gmail\.com\, Jan Dubois \jand@&#8203;activestate\.com\, Edward Moy \emoy@&#8203;apple\.com\, "Craig A. Berry" \craig\.a\.berry@&#8203;gmail\.com\, perl5-porters@​perl.org\, perlbug-followup@​perl.org

So why do you stick that Mail-Followup-To line in there? Is this gmail stupidity\, your emails client stupidity\, some kind of workaround of general email stupidity\, merely an example of the standard hatefulness of email clients or what?

I don't know why gmail reacts that way to it. mutt will reacts to it in the way that I want - it means that if a mutt user does "reply to all"\, it takes me out of the the Cc​: (because I am already on the list).

I assume that it's gmail being stupid\, or maybe just being ignorant\, because it doesn't recognise your address in that list as being "you"\, the person sending the e-mail.

I wonder if rjbs knows.

Nicholas Clark

[p5pRT]

From @obra

Not actually a 5.12.0 blocker. Unlinking

[p5pRT]

@iabyn - Status changed from 'open' to 'stalled'

[p5pRT]

From @iabyn

Given the unlikelihood of any more 5.8 releases\, and the lack of interest in becoming 5.8 pumpking\, I'm marking this as stalled/wontfix

[p5pRT]

From @doy

Closing.

-doy

[p5pRT]

From [Unknown Contact. See original ticket]

Closing.

-doy

[p5pRT]

@doy - Status changed from 'stalled' to 'resolved'

[p5pRT]

From @cpansprout

On Fri Jul 06 16​:29​:13 2012\, doy wrote​:

Closing.

Wait a moment. In case somebody wants to build 5.8.x\, it might be useful to have this binary-incompatibility-fixing patch applied to maint-5.8. (The same thing has happened since 5.6.2 on the maint-5.6 branch.) The only reason it hasn’t happened is that nobody could decide who was responsible for that branch any more.

If nobody objects\, I’ll apply it.

--

Father Chrysostomos

[p5pRT]

From [Unknown Contact. See original ticket]

On Fri Jul 06 16​:29​:13 2012\, doy wrote​:

Closing.

Wait a moment. In case somebody wants to build 5.8.x\, it might be useful to have this binary-incompatibility-fixing patch applied to maint-5.8. (The same thing has happened since 5.6.2 on the maint-5.6 branch.) The only reason it hasn’t happened is that nobody could decide who was responsible for that branch any more.

If nobody objects\, I’ll apply it.

--

Father Chrysostomos

[p5pRT]

From @rjbs

* Father Chrysostomos via RT \perlbug\-comment@&#8203;perl\.org [2012-07-06T20​:56​:06]

On Fri Jul 06 16​:29​:13 2012\, doy wrote​:

Closing.

Wait a moment. In case somebody wants to build 5.8.x\, it might be useful to have this binary-incompatibility-fixing patch applied to maint-5.8. (The same thing has happened since 5.6.2 on the maint-5.6 branch.) The only reason it hasn’t happened is that nobody could decide who was responsible for that branch any more.

If nobody objects\, I’ll apply it.

Go ahead.

-- rjbs

[p5pRT]

From @cpansprout

On Fri Jul 06 18​:12​:21 2012\, perl.p5p@​rjbs.manxome.org wrote​:

* Father Chrysostomos via RT \perlbug\-comment@&#8203;perl\.org [2012-07- 06T20​:56​:06]

On Fri Jul 06 16​:29​:13 2012\, doy wrote​:

Closing.

Wait a moment. In case somebody wants to build 5.8.x\, it might be useful to have this binary-incompatibility-fixing patch applied to maint-5.8. (The same thing has happened since 5.6.2 on the maint- 5.6 branch.) The only reason it hasn’t happened is that nobody could decide who was responsible for that branch any more.

If nobody objects\, I’ll apply it.

Go ahead.

I have just applied it as 03fe696d61d.

--

Father Chrysostomos