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

Owner: Nobody
Requestors: jpl.jpl [at] gmail.com
Cc:
AdminCc:

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



Date: Mon, 28 Aug 2017 18:41:15 -0400
To: perlbug [...] perl.org
Subject: Fix potential segfault from pp_sort.c
From: "John P. Linderman" <jpl.jpl [...] gmail.com>
Attached is what perlbug left in my mail spool. Mail cannot be sent from my PC.
Download perlbug.txt
text/plain 6.3k

Message body is not shown because sender requested not to inline it.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 637b
On Mon, 28 Aug 2017 22:41:29 GMT, jpl.jpl@gmail.com wrote: Show quoted text
> Attached is what perlbug left in my mail spool. Mail cannot be sent from my > PC.
In the years since the individual tests in lib/sort.t were created, it's become customary to produce test output that explicitly states that we did not have a crash or segfault where previously we would have had one. Hence, for the modifications for lib/sort.t I would prefer the '0002' patch I'm attaching to this RT. Since we prefer spaces to hard tabs in newly added code, I have also reformatted one test block. Please review. Thank you very much. -- James E Keenan (jkeenan@cpan.org)
Subject: 0001-Change-save-restore-behavior-for-comparisons.patch
From 5fff7c19cd13984f53bc77b360fcdf90cd375551 Mon Sep 17 00:00:00 2001 From: jpl <jpl.jpl@gmail.com> Date: Mon, 28 Aug 2017 09:54:15 -0400 Subject: [PATCH 1/2] Change save/restore behavior for comparisons S_mergesortsv was saving the current comparison routine only when the SORTf_DESC flag was set, but "restoring" it when ANY flag was set. When some flag other than SORTf_DESC was set, this could lead to the pointer to the comparison routine being set to NULL, triggering a segfault when the routine was subsequently invoked. --- lib/sort.t | 17 ++++++++++++++++- pp_sort.c | 2 +- 2 files changed, 17 insertions(+), 2 deletions(-) diff --git a/lib/sort.t b/lib/sort.t index b44269a..1ff3832 100644 --- a/lib/sort.t +++ b/lib/sort.t @@ -130,9 +130,24 @@ sub main { } } -# Test with no pragma still loaded -- stability expected (this is a mergesort) +# Test with no pragma yet loaded. Stability is expected from default sort. main(sub { sort {&{$_[0]}} @{$_[1]} }, 0); +# Verify that we have eliminated the segfault that could be triggered +# by invoking a sort as part of a comparison routine. +# No need for an explicit test. If we don't segfault, we're good. + +{ + sub dumbsort { + my ($a, $b) = @_; + use sort qw( defaults stable ); + my @ignore = sort (5,4,3,2,1); + return $a <=> $b; + } + use sort qw( defaults _qsort stable ); + my @nested = sort { dumbsort($a,$b) } (3,2,2,1); +} + { use sort qw(_qsort); my $sort_current; BEGIN { $sort_current = sort::current(); } diff --git a/pp_sort.c b/pp_sort.c index ee1dc5d..e0f4182 100644 --- a/pp_sort.c +++ b/pp_sort.c @@ -558,7 +558,7 @@ S_mergesortsv(pTHX_ gptr *base, size_t nmemb, SVCOMPARE_t cmp, U32 flags) } done: if (aux != small) Safefree(aux); /* free iff allocated */ - if (flags) { + if (savecmp != NULL) { PL_sort_RealCmp = savecmp; /* Restore current comparison routine, if any */ } return; -- 2.7.4
Subject: 0002-Make-explicit-that-we-did-not-segfault.patch
From a97b249566872bfc9f297c723d08f847e696eabf Mon Sep 17 00:00:00 2001 From: James E Keenan <jkeenan@cpan.org> Date: Mon, 28 Aug 2017 21:57:28 -0400 Subject: [PATCH 2/2] Make explicit that we did not segfault. Do not use hard tabs in newly added test blocks. --- lib/sort.t | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/lib/sort.t b/lib/sort.t index 1ff3832..8688bb2 100644 --- a/lib/sort.t +++ b/lib/sort.t @@ -28,6 +28,7 @@ use warnings; use Test::More tests => @TestSizes * 2 # sort() tests * 6 # number of pragmas to test + 1 # extra test for qsort instability + + 1 # extra test to demonstrate no segfault + 3 # tests for sort::current + 3; # tests for "defaults" and "no sort" @@ -135,17 +136,17 @@ main(sub { sort {&{$_[0]}} @{$_[1]} }, 0); # Verify that we have eliminated the segfault that could be triggered # by invoking a sort as part of a comparison routine. -# No need for an explicit test. If we don't segfault, we're good. { sub dumbsort { - my ($a, $b) = @_; - use sort qw( defaults stable ); - my @ignore = sort (5,4,3,2,1); - return $a <=> $b; + my ($a, $b) = @_; + use sort qw( defaults stable ); + my @ignore = sort (5,4,3,2,1); + return $a <=> $b; } use sort qw( defaults _qsort stable ); my @nested = sort { dumbsort($a,$b) } (3,2,2,1); + pass("No segfault when sort invoked as part of comparison routine: RT #131984"); } { -- 2.7.4
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 790b
On Tue, 29 Aug 2017 02:06:28 GMT, jkeenan wrote: Show quoted text
> On Mon, 28 Aug 2017 22:41:29 GMT, jpl.jpl@gmail.com wrote:
> > Attached is what perlbug left in my mail spool. Mail cannot be sent > > from my > > PC.
> > In the years since the individual tests in lib/sort.t were created, > it's become customary to produce test output that explicitly states > that we did not have a crash or segfault where previously we would > have had one. > > Hence, for the modifications for lib/sort.t I would prefer the '0002' > patch I'm attaching to this RT. > > Since we prefer spaces to hard tabs in newly added code, I have also > reformatted one test block. > > Please review. Thank you very much.
Available for smoking in branch: smoke-me/jkeenan/jpl/131984-sort -- James E Keenan (jkeenan@cpan.org)
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 305b
On Mon, 28 Aug 2017 15:41:29 -0700, jpl.jpl@gmail.com wrote: Show quoted text
> Attached is what perlbug left in my mail spool. Mail cannot be sent from my > PC.
The patch makes sense to me. I do suspect both before and after your change there's an issue if an inner sort dies and is caught within the outer sort. Tony
Date: Tue, 29 Aug 2017 07:00:09 -0400
To: perlbug-followup [...] perl.org
Subject: Re: [perl #131984] Fix potential segfault from pp_sort.c
From: "John P. Linderman" <jpl.jpl [...] gmail.com>
Download (untitled) / with headers
text/plain 4.7k
The changes look good.  I'll try to remember to use blanks instead of tabs in future changes to test code. Now that I (think I) know why perlbug failed, I'll generate the changes and send them from google mail in the future.

On Mon, Aug 28, 2017 at 10:06 PM, James E Keenan via RT <perlbug-followup@perl.org> wrote:
Show quoted text
On Mon, 28 Aug 2017 22:41:29 GMT, jpl.jpl@gmail.com wrote:
> Attached is what perlbug left in my mail spool. Mail cannot be sent from my
> PC.

In the years since the individual tests in lib/sort.t were created, it's become customary to produce test output that explicitly states that we did not have a crash or segfault where previously we would have had one.

Hence, for the modifications for lib/sort.t I would prefer the '0002' patch I'm attaching to this RT.

Since we prefer spaces to hard tabs in newly added code, I have also reformatted one test block.

Please review.  Thank you very much.
--
James E Keenan (jkeenan@cpan.org)

From 5fff7c19cd13984f53bc77b360fcdf90cd375551 Mon Sep 17 00:00:00 2001
From: jpl <jpl.jpl@gmail.com>
Date: Mon, 28 Aug 2017 09:54:15 -0400
Subject: [PATCH 1/2] Change save/restore behavior for comparisons

S_mergesortsv was saving the current comparison routine only when the
SORTf_DESC flag was set, but "restoring" it when ANY flag was set.
When some flag other than SORTf_DESC was set, this could lead to
the pointer to the comparison routine being set to NULL,
triggering a segfault when the routine was subsequently invoked.
---
 lib/sort.t | 17 ++++++++++++++++-
 pp_sort.c  |  2 +-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/lib/sort.t b/lib/sort.t
index b44269a..1ff3832 100644
--- a/lib/sort.t
+++ b/lib/sort.t
@@ -130,9 +130,24 @@ sub main {
     }
 }

-# Test with no pragma still loaded -- stability expected (this is a mergesort)
+# Test with no pragma yet loaded. Stability is expected from default sort.
 main(sub { sort {&{$_[0]}} @{$_[1]} }, 0);

+# Verify that we have eliminated the segfault that could be triggered
+# by invoking a sort as part of a comparison routine.
+# No need for an explicit test. If we don't segfault, we're good.
+
+{
+    sub dumbsort {
+       my ($a, $b) = @_;
+       use sort qw( defaults stable );
+       my @ignore = sort (5,4,3,2,1);
+       return $a <=> $b;
+    }
+    use sort qw( defaults _qsort stable );
+    my @nested = sort { dumbsort($a,$b) } (3,2,2,1);
+}
+
 {
     use sort qw(_qsort);
     my $sort_current; BEGIN { $sort_current = sort::current(); }
diff --git a/pp_sort.c b/pp_sort.c
index ee1dc5d..e0f4182 100644
--- a/pp_sort.c
+++ b/pp_sort.c
@@ -558,7 +558,7 @@ S_mergesortsv(pTHX_ gptr *base, size_t nmemb, SVCOMPARE_t cmp, U32 flags)
     }
   done:
     if (aux != small) Safefree(aux);   /* free iff allocated */
-    if (flags) {
+    if (savecmp != NULL) {
         PL_sort_RealCmp = savecmp;     /* Restore current comparison routine, if any */
     }
     return;
--
2.7.4


From a97b249566872bfc9f297c723d08f847e696eabf Mon Sep 17 00:00:00 2001
From: James E Keenan <jkeenan@cpan.org>
Date: Mon, 28 Aug 2017 21:57:28 -0400
Subject: [PATCH 2/2] Make explicit that we did not segfault.

Do not use hard tabs in newly added test blocks.
---
 lib/sort.t | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/lib/sort.t b/lib/sort.t
index 1ff3832..8688bb2 100644
--- a/lib/sort.t
+++ b/lib/sort.t
@@ -28,6 +28,7 @@ use warnings;
 use Test::More tests => @TestSizes * 2 # sort() tests
                        * 6             # number of pragmas to test
                        + 1             # extra test for qsort instability
+                       + 1             # extra test to demonstrate no segfault
                        + 3             # tests for sort::current
                        + 3;            # tests for "defaults" and "no sort"

@@ -135,17 +136,17 @@ main(sub { sort {&{$_[0]}} @{$_[1]} }, 0);

 # Verify that we have eliminated the segfault that could be triggered
 # by invoking a sort as part of a comparison routine.
-# No need for an explicit test. If we don't segfault, we're good.

 {
     sub dumbsort {
-       my ($a, $b) = @_;
-       use sort qw( defaults stable );
-       my @ignore = sort (5,4,3,2,1);
-       return $a <=> $b;
+        my ($a, $b) = @_;
+        use sort qw( defaults stable );
+        my @ignore = sort (5,4,3,2,1);
+        return $a <=> $b;
     }
     use sort qw( defaults _qsort stable );
     my @nested = sort { dumbsort($a,$b) } (3,2,2,1);
+    pass("No segfault when sort invoked as part of comparison routine: RT #131984");
 }

 {
--
2.7.4



To: perlbug-followup [...] perl.org
Date: Tue, 29 Aug 2017 07:15:57 -0400
Subject: Re: [perl #131984] Fix potential segfault from pp_sort.c
From: "John P. Linderman" <jpl.jpl [...] gmail.com>
I agree, Tony, but I don't know what to do about it. The saving grace, I guess, is that invoking a sort as part of a comparison routine is bizarre. It would have to be invoked for side effects only, because the result of comparing two elements should depend only on the values of those elements. And it's a stretch for me to figure out why that might be useful. Which is why my test case does nothing with the results of the nested sort. If we could disallow nested sorts, I doubt that it would break any code, and might expose some logic errors... "I thought I could take a look at the array as it was being sorted".

On Tue, Aug 29, 2017 at 12:52 AM, Tony Cook via RT <perlbug-followup@perl.org> wrote:
Show quoted text
On Mon, 28 Aug 2017 15:41:29 -0700, jpl.jpl@gmail.com wrote:
> Attached is what perlbug left in my mail spool. Mail cannot be sent from my
> PC.


The patch makes sense to me.

I do suspect both before and after your change there's an issue if an inner sort dies and is caught within the outer sort.

Tony

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 319b
On Tue, 29 Aug 2017 04:16:28 -0700, jpl.jpl@gmail.com wrote: Show quoted text
> The saving grace, I > guess, is that invoking a sort as part of a comparison routine is bizarre.
Done indirectly, it's not so surprising - { $a->method <=> $b->method } is a perfectly reasonable comparator, and the method may do all sorts of things. Hugo
To: perlbug-followup [...] perl.org
Subject: Re: [perl #131984] Fix potential segfault from pp_sort.c
From: "John P. Linderman" <jpl.jpl [...] gmail.com>
Date: Tue, 29 Aug 2017 16:54:01 -0400
The method can do all sorts😀 of things, but it must always return consistent results for the same $a and $b. That's the "contract" between sort and the user. So the outcome of anything done by the method must not influence what is returned. One might produce a report of how the top 10 stocks change from comparison to comparison, but that's a stretch, and prohibiting it has beneficial effects, as Tony observed. If I could see a reasonable comparator that involved a sort, I'd soften my position, but I have no intention (nor ability) to prohibit nested sorts, so my position isn't particularly important.

On Tue, Aug 29, 2017 at 3:05 PM, Hugo van der Sanden via RT <perlbug-followup@perl.org> wrote:
Show quoted text
On Tue, 29 Aug 2017 04:16:28 -0700, jpl.jpl@gmail.com wrote:
> The saving grace, I
> guess, is that invoking a sort as part of a comparison routine is bizarre.

Done indirectly, it's not so surprising - { $a->method <=> $b->method } is a perfectly reasonable comparator, and the method may do all sorts of things.

Hugo

From: "John P. Linderman" <jpl.jpl [...] gmail.com>
Subject: Re: [perl #131984] Fix potential segfault from pp_sort.c
Date: Wed, 30 Aug 2017 09:26:32 -0400
To: perlbug-followup [...] perl.org
Download (untitled) / with headers
text/plain 807b
Here's a case that I find plausible. You have an array of hashrefs, each describing statistics about a sample dataset (that is part of each hash). You want to sort the hashrefs on the median of their datasets. So the comparison function sorts the dataset (unless it has already been sorted, so it's only done once), and uses the sorted dataset to determine the median.

On Tue, Aug 29, 2017 at 3:05 PM, Hugo van der Sanden via RT <perlbug-followup@perl.org> wrote:
Show quoted text
On Tue, 29 Aug 2017 04:16:28 -0700, jpl.jpl@gmail.com wrote:
> The saving grace, I
> guess, is that invoking a sort as part of a comparison routine is bizarre.

Done indirectly, it's not so surprising - { $a->method <=> $b->method } is a perfectly reasonable comparator, and the method may do all sorts of things.

Hugo

Subject: Re: [perl #131984] Fix potential segfault from pp_sort.c
From: Zefram <zefram [...] fysh.org>
Date: Wed, 30 Aug 2017 04:34:07 +0100
To: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 221b
John P. Linderman wrote: Show quoted text
> If I could see a >reasonable comparator that involved a sort,
{ join("\0", sort $a->flanges) cmp join("\0", sort $b->flanges) } -zefram
To: perlbug-followup [...] perl.org
Date: Mon, 4 Sep 2017 11:01:24 -0400
From: "John P. Linderman" <jpl.jpl [...] gmail.com>
Subject: Re: [perl #131984] Fix potential segfault from pp_sort.c
Download (untitled) / with headers
text/plain 4.7k
Is this commit waiting for something from me? I see that other commits to pp_sort.c have been made:

commit f6107ca24b4cf22dcf7fd69d65612ad718c48fca

I'd like to continue work on destabilization, but I'd like to start from a point where the segfault problem has been addressed.

On Mon, Aug 28, 2017 at 10:06 PM, James E Keenan via RT <perlbug-followup@perl.org> wrote:
Show quoted text
On Mon, 28 Aug 2017 22:41:29 GMT, jpl.jpl@gmail.com wrote:
> Attached is what perlbug left in my mail spool. Mail cannot be sent from my
> PC.

In the years since the individual tests in lib/sort.t were created, it's become customary to produce test output that explicitly states that we did not have a crash or segfault where previously we would have had one.

Hence, for the modifications for lib/sort.t I would prefer the '0002' patch I'm attaching to this RT.

Since we prefer spaces to hard tabs in newly added code, I have also reformatted one test block.

Please review.  Thank you very much.
--
James E Keenan (jkeenan@cpan.org)

From 5fff7c19cd13984f53bc77b360fcdf90cd375551 Mon Sep 17 00:00:00 2001
From: jpl <jpl.jpl@gmail.com>
Date: Mon, 28 Aug 2017 09:54:15 -0400
Subject: [PATCH 1/2] Change save/restore behavior for comparisons

S_mergesortsv was saving the current comparison routine only when the
SORTf_DESC flag was set, but "restoring" it when ANY flag was set.
When some flag other than SORTf_DESC was set, this could lead to
the pointer to the comparison routine being set to NULL,
triggering a segfault when the routine was subsequently invoked.
---
 lib/sort.t | 17 ++++++++++++++++-
 pp_sort.c  |  2 +-
 2 files changed, 17 insertions(+), 2 deletions(-)

diff --git a/lib/sort.t b/lib/sort.t
index b44269a..1ff3832 100644
--- a/lib/sort.t
+++ b/lib/sort.t
@@ -130,9 +130,24 @@ sub main {
     }
 }

-# Test with no pragma still loaded -- stability expected (this is a mergesort)
+# Test with no pragma yet loaded. Stability is expected from default sort.
 main(sub { sort {&{$_[0]}} @{$_[1]} }, 0);

+# Verify that we have eliminated the segfault that could be triggered
+# by invoking a sort as part of a comparison routine.
+# No need for an explicit test. If we don't segfault, we're good.
+
+{
+    sub dumbsort {
+       my ($a, $b) = @_;
+       use sort qw( defaults stable );
+       my @ignore = sort (5,4,3,2,1);
+       return $a <=> $b;
+    }
+    use sort qw( defaults _qsort stable );
+    my @nested = sort { dumbsort($a,$b) } (3,2,2,1);
+}
+
 {
     use sort qw(_qsort);
     my $sort_current; BEGIN { $sort_current = sort::current(); }
diff --git a/pp_sort.c b/pp_sort.c
index ee1dc5d..e0f4182 100644
--- a/pp_sort.c
+++ b/pp_sort.c
@@ -558,7 +558,7 @@ S_mergesortsv(pTHX_ gptr *base, size_t nmemb, SVCOMPARE_t cmp, U32 flags)
     }
   done:
     if (aux != small) Safefree(aux);   /* free iff allocated */
-    if (flags) {
+    if (savecmp != NULL) {
         PL_sort_RealCmp = savecmp;     /* Restore current comparison routine, if any */
     }
     return;
--
2.7.4


From a97b249566872bfc9f297c723d08f847e696eabf Mon Sep 17 00:00:00 2001
From: James E Keenan <jkeenan@cpan.org>
Date: Mon, 28 Aug 2017 21:57:28 -0400
Subject: [PATCH 2/2] Make explicit that we did not segfault.

Do not use hard tabs in newly added test blocks.
---
 lib/sort.t | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/lib/sort.t b/lib/sort.t
index 1ff3832..8688bb2 100644
--- a/lib/sort.t
+++ b/lib/sort.t
@@ -28,6 +28,7 @@ use warnings;
 use Test::More tests => @TestSizes * 2 # sort() tests
                        * 6             # number of pragmas to test
                        + 1             # extra test for qsort instability
+                       + 1             # extra test to demonstrate no segfault
                        + 3             # tests for sort::current
                        + 3;            # tests for "defaults" and "no sort"

@@ -135,17 +136,17 @@ main(sub { sort {&{$_[0]}} @{$_[1]} }, 0);

 # Verify that we have eliminated the segfault that could be triggered
 # by invoking a sort as part of a comparison routine.
-# No need for an explicit test. If we don't segfault, we're good.

 {
     sub dumbsort {
-       my ($a, $b) = @_;
-       use sort qw( defaults stable );
-       my @ignore = sort (5,4,3,2,1);
-       return $a <=> $b;
+        my ($a, $b) = @_;
+        use sort qw( defaults stable );
+        my @ignore = sort (5,4,3,2,1);
+        return $a <=> $b;
     }
     use sort qw( defaults _qsort stable );
     my @nested = sort { dumbsort($a,$b) } (3,2,2,1);
+    pass("No segfault when sort invoked as part of comparison routine: RT #131984");
 }

 {
--
2.7.4



Subject: Re: [perl #131984] Fix potential segfault from pp_sort.c
From: "John P. Linderman" <jpl.jpl [...] gmail.com>
To: perlbug-followup [...] perl.org
Date: Sun, 10 Sep 2017 09:53:58 -0400
Download (untitled) / with headers
text/plain 823b
There's a Draconian, but I think effective, workaround. Assign the original comparison routine to PL_sort_RealCmp before every comparison. That's NlogN assignments rather than 1, but it's probably insignificant relative to all the other stuff that happens around comparisons. This makes one appreciate how painful it is that C does not support closures. The authors of go didn't repeat that oversight.

On Tue, Aug 29, 2017 at 12:52 AM, Tony Cook via RT <perlbug-followup@perl.org> wrote:
Show quoted text
On Mon, 28 Aug 2017 15:41:29 -0700, jpl.jpl@gmail.com wrote:
> Attached is what perlbug left in my mail spool. Mail cannot be sent from my
> PC.


The patch makes sense to me.

I do suspect both before and after your change there's an issue if an inner sort dies and is caught within the outer sort.

Tony

From: Tony Cook <tony [...] develop-help.com>
Subject: Re: [perl #131984] Fix potential segfault from pp_sort.c
Date: Mon, 11 Sep 2017 09:39:35 +1000
CC: perlbug-followup [...] perl.org
To: "John P. Linderman" <jpl.jpl [...] gmail.com>
Download (untitled) / with headers
text/plain 1.1k
On Sun, Sep 10, 2017 at 09:53:58AM -0400, John P. Linderman wrote: Show quoted text
> On Tue, Aug 29, 2017 at 12:52 AM, Tony Cook via RT < > perlbug-followup@perl.org> wrote: >
> > On Mon, 28 Aug 2017 15:41:29 -0700, jpl.jpl@gmail.com wrote:
> > > Attached is what perlbug left in my mail spool. Mail cannot be sent from
> > my
> > > PC.
> > > > > > The patch makes sense to me. > > > > I do suspect both before and after your change there's an issue if an > > inner sort dies and is caught within the outer sort. > > > > Tony > >
> There's a Draconian, but I think effective, workaround. Assign the original > comparison routine to PL_sort_RealCmp before *every* comparison. That's > NlogN assignments rather than 1, but it's probably insignificant relative > to all the other stuff that happens around comparisons. This makes one > appreciate how painful it is that C does not support closures. The authors > of *go* didn't repeat that oversight.
The general solution for this type of thing in core is usually a SAVE*() macro such as SAVEPPTR() (see scope.h, scope.c), but function pointers are generally not compatible with data pointers. So we'd need a new macro, code in scope.c to handle it, and a call to it in pp_sort.c Tony
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 482b
On Mon, 04 Sep 2017 08:03:29 -0700, jpl.jpl@gmail.com wrote: Show quoted text
> Is this commit waiting for something from me? I see that other commits > to > pp_sort.c have been made: > > commit f6107ca24b4cf22dcf7fd69d65612ad718c48fca > > I'd like to continue work on destabilization, but I'd like to start > from a > point where the segfault problem has been addressed.
Thanks, applied as 0e1d050c8bc9db9872018aa565cc957f8169e50c. Leaving open for now, since we still have a known issue. Tony


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