Mailing List Archive: Perl: porters

[perl #60374] Safe.pm sort {} bug with -Dusethreads

1 2

View All

Index | Next | Previous | View Threaded

perlbug-followup at perl

Nov 6, 2008, 7:35 AM

Post #1 of 30 (1040 views)
Permalink

[perl #60374] Safe.pm sort {} bug with -Dusethreads

# New Ticket Created by "Alex Hunsaker"
# Please include the string: [perl #60374]
# in the subject line of all future correspondence about this issue.
# <URL: http://rt.perl.org/rt3/Ticket/Display.html?id=60374 >

When using a threading perl and you reval an anon sub that contains a sort,
a/$b loose their values. Both 5.8.8 and 5.10.0 seem to be affected.

(see attached perl.v for perl -V output)
-Dusethreads
perl tsafe.pl
debug:
debug:
debug:
debug:
debug:
debug:
debug:
debug:
debug: 5 4 3 2 1

without -Dusethreads
perl1 tsafe.pl
debug: 4
debug: 2
debug: 2
debug: 3
debug: 1
debug: 1 2 3 4 5

tsafe.pl
==========
use Safe;

my $safe = Safe->new('PLPerl');
$safe->permit_only(':default');
$safe->permit(qw(sort));
$safe->share(qw(&debug));

sub debug {
print "debug: ". (shift) . "\n";
}

my $func = $safe->reval(<<'z');
sub {
my @c = sort { debug("$b"); "$a" <=> $b } qw(5 4 3 2 1);
debug(join(" ", @c));
return;
}
z

#my $f = eval 'package PLPerl; sub { @_=(); $func->(); }';
$func->();

die $@ if($@);

Attachments:

perl.v (2.96 KB)

perl1.v (2.14 KB)

tsafe.pl (0.40 KB)

badalex at gmail

Oct 6, 2009, 1:33 PM

Post #2 of 30 (968 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Tue, Oct 6, 2009 at 13:55, Tim Bunce via RT
<perlbug-followup [at] perl> wrote:
> Any news of progress with this bug?

Nope still broke for me on 5.10.1

Here are the workaround I know about:
1) dont use $a and $b in sort, use @_
2) your way of adding *a and *b, but that only works as long as the
package stays the same...
3) declare the package at the top of reval, i.e.
my $safe = Safe->new('PLPerl');
$safe->permit(qw(sort));
my $func = $safe->reval(<<'eval');
package PLPerl;
sub {
sort { "$a" cmp "$b" } qw(works now);
}
eval

$func->();

4) fix perl :) as mentioned in the previous message

> Meanwhile, I have a workaround: explicitly share the globs for a and b. In other words, add *a
> and * b to the arguments of the share() method:
>
> $safe->share(qw(&debug *a *b));

Yeah as noted above that should work. Unless you ever sort inside a
different package than you gave to Safe->new() (see the below test
case)

use Safe();

my $safe = Safe->new('PLPerl');
$safe->permit_only(':default');
$safe->permit(qw(sort));
$safe->share(qw(&PLPerl::debug *a *b));

my $func = $safe->reval(<<'z');
sub {
package PLPrl;
my @c = sort { PLPerl::debug("$a ". $b); "$a" <=> $b } qw(5 4 3 2 1);
PLPerl::debug(join(" ", @c));
return;
}
z

$func->();

package PLPerl;
sub debug {
print "debug: ". (shift) . "\n";
}

$ perl tsafe.pl
debug:
debug:
debug:
debug:
debug:
debug:
debug:
debug:
debug: 5 4 3 2 1

rgs at consttype

Oct 7, 2009, 8:22 AM

Post #3 of 30 (962 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

2009/10/6 Tim Bunce via RT <perlbug-followup [at] perl>:
> Any news of progress with this bug?
>
> Meanwhile, I have a workaround: explicitly share the globs for a and b. In other words, add *a
> and * b to the arguments of the share() method:
>
> $safe->share(qw(&debug *a *b));

I don't think that *a and *b should be added to the default sharelist
of Safe. Actually the only glob there is *_, and I think it should
remain as is.

The bug is most likely in the sort implementation, which is
notoriously thread-unsafe when it invokes sort subs.

In short, my advice would be : don't use sort() at all with a threaded perl.

david at kineticode

Oct 7, 2009, 9:13 AM

Post #4 of 30 (962 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Oct 7, 2009, at 8:22 AM, Rafael Garcia-Suarez wrote:

> The bug is most likely in the sort implementation, which is
> notoriously thread-unsafe when it invokes sort subs.
>
> In short, my advice would be : don't use sort() at all with a
> threaded perl.

Say what? Sure, on current releases, but surely that should be fixed.
There are more and more threaded Perls every day�

David

rgs at consttype

Oct 7, 2009, 10:24 AM

Post #5 of 30 (962 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

2009/10/7 David E. Wheeler <david [at] kineticode>:
> On Oct 7, 2009, at 8:22 AM, Rafael Garcia-Suarez wrote:
>
>> The bug is most likely in the sort implementation, which is
>> notoriously thread-unsafe when it invokes sort subs.
>>
>> In short, my advice would be : don't use sort() at all with a threaded
>> perl.
>
> Say what? Sure, on current releases, but surely that should be fixed. There
> are more and more threaded Perls every day�

Even if we manage someone to fix threading, this will slow down
sort(). Threading also has a non-negligeable performance impact on
memory and speed of every perl program.

I think we should advice people in INSTALL to build with threading
only if they really need it, and tell OS vendors to disable threading
on their system perls.

david at kineticode

Oct 7, 2009, 10:26 AM

Post #6 of 30 (961 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Oct 7, 2009, at 10:24 AM, Rafael Garcia-Suarez wrote:

> Even if we manage someone to fix threading, this will slow down
> sort(). Threading also has a non-negligeable performance impact on
> memory and speed of every perl program.
>
> I think we should advice people in INSTALL to build with threading
> only if they really need it, and tell OS vendors to disable threading
> on their system perls.

Snow Leopard ships with a threaded Perl. Hell, I think Leopard did.
That cat might have left the bag.

Best,

David

jand at activestate

Oct 7, 2009, 6:17 PM

Post #7 of 30 (960 views)
Permalink

RE: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Wed, 07 Oct 2009, Rafael Garcia-Suarez wrote:
>
> The bug is most likely in the sort implementation, which is
> notoriously thread-unsafe when it invokes sort subs.
>
> In short, my advice would be : don't use sort() at all with a threaded perl.

Just to be sure: That advice is in the context of using Safe.pm,
right? Or are there problems with sort() ourside safe compartments
under threading as well? Are there any open bugs about them?

Cheers,
-Jan

rgs at consttype

Oct 7, 2009, 11:25 PM

Post #8 of 30 (960 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

2009/10/8 Jan Dubois <jand [at] activestate>:
> On Wed, 07 Oct 2009, Rafael Garcia-Suarez wrote:
>>
>> The bug is most likely in the sort implementation, which is
>> notoriously thread-unsafe when it invokes sort subs.
>>
>> In short, my advice would be : don't use sort() at all with a threaded perl.
>
> Just to be sure: That advice is in the context of using Safe.pm,
> right? �Or are there problems with sort() ourside safe compartments
> under threading as well? �Are there any open bugs about them?

No, sort is thread-unsafe as long as the sort function is custom (and
not XS, IIRC). That's basically because it's called in a super-fast
way, for speed. I think there are bugs, but can't find one rapidly.

demerphq at gmail

Oct 8, 2009, 3:56 AM

Post #9 of 30 (960 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

2009/10/8 Rafael Garcia-Suarez <rgs [at] consttype>:
> 2009/10/8 Jan Dubois <jand [at] activestate>:
>> On Wed, 07 Oct 2009, Rafael Garcia-Suarez wrote:
>>>
>>> The bug is most likely in the sort implementation, which is
>>> notoriously thread-unsafe when it invokes sort subs.
>>>
>>> In short, my advice would be : don't use sort() at all with a threaded perl.
>>
>> Just to be sure: That advice is in the context of using Safe.pm,
>> right? �Or are there problems with sort() ourside safe compartments
>> under threading as well? �Are there any open bugs about them?
>
> No, sort is thread-unsafe as long as the sort function is custom (and
> not XS, IIRC). That's basically because it's called in a super-fast
> way, for speed. I think there are bugs, but can't find one rapidly.

Considering all Win32 builds pretty much are threaded id be surprised
if it was that easy. Having said that, maybe this explains some weird
win32 bugs...

Yves

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

lists.perl.perl5-porters at csjewell

Oct 8, 2009, 8:58 AM

Post #10 of 30 (959 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Wed, 07 Oct 2009 10:26 -0700, "David E. Wheeler"
<david [at] kineticode> wrote:
> On Oct 7, 2009, at 10:24 AM, Rafael Garcia-Suarez wrote:
>
> > Even if we manage someone to fix threading, this will slow down
> > sort(). Threading also has a non-negligeable performance impact on
> > memory and speed of every perl program.
> >
> > I think we should advice people in INSTALL to build with threading
> > only if they really need it, and tell OS vendors to disable threading
> > on their system perls.
>
> Snow Leopard ships with a threaded Perl. Hell, I think Leopard did.
> That cat might have left the bag.

And Strawberry is threaded. If I switched it to non-threaded now, I'd
be stood up to a wall and shot by the Padre people (they require
threading) among others.

--Curtis
--
Curtis Jewell
csjewell [at] cpan http://csjewell.dreamwidth.org/
perl [at] csjewell http://csjewell.comyr.org/perl/

"Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

Strawberry Perl for Windows betas: http://strawberryperl.com/beta/

david at kineticode

Oct 8, 2009, 9:41 AM

Post #11 of 30 (960 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Oct 7, 2009, at 11:25 PM, Rafael Garcia-Suarez wrote:

>> Just to be sure: That advice is in the context of using Safe.pm,
>> right? Or are there problems with sort() ourside safe compartments
>> under threading as well? Are there any open bugs about them?
>
> No, sort is thread-unsafe as long as the sort function is custom (and
> not XS, IIRC). That's basically because it's called in a super-fast
> way, for speed. I think there are bugs, but can't find one rapidly.

It seems to me that such bugs should be fixed as they're identified.
Even if sorting becomes slower with threads, I'll take correct over
fast any day.

Best,

David

rgs at consttype

Oct 8, 2009, 10:00 AM

Post #12 of 30 (961 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

2009/10/8 David E. Wheeler <david [at] kineticode>:
> On Oct 7, 2009, at 11:25 PM, Rafael Garcia-Suarez wrote:
>
>>> Just to be sure: That advice is in the context of using Safe.pm,
>>> right? �Or are there problems with sort() ourside safe compartments
>>> under threading as well? �Are there any open bugs about them?
>>
>> No, sort is thread-unsafe as long as the sort function is custom (and
>> not XS, IIRC). That's basically because it's called in a super-fast
>> way, for speed. I think there are bugs, but can't find one rapidly.
>
> It seems to me that such bugs should be fixed as they're identified. Even if
> sorting becomes slower with threads, I'll take correct over fast any day.

I wholeheartedly agree. Someone should fix that. It's just not my
itch: I don't build or use threaded perls.

h.m.brand at xs4all

Oct 8, 2009, 10:05 AM

Post #13 of 30 (957 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Thu, 8 Oct 2009 09:41:42 -0700, "David E. Wheeler"
<david [at] kineticode> wrote:

> On Oct 7, 2009, at 11:25 PM, Rafael Garcia-Suarez wrote:
>
> >> Just to be sure: That advice is in the context of using Safe.pm,
> >> right? Or are there problems with sort() ourside safe compartments
> >> under threading as well? Are there any open bugs about them?
> >
> > No, sort is thread-unsafe as long as the sort function is custom (and
> > not XS, IIRC). That's basically because it's called in a super-fast
> > way, for speed. I think there are bugs, but can't find one rapidly.
>
> It seems to me that such bugs should be fixed as they're identified.
> Even if sorting becomes slower with threads, I'll take correct over
> fast any day.

Then use an unthreaded perl, and you've got correct behaviour :)

As long as it doesn't slow down unthreaded builds, I'm fine with any
solution. I have never ever needed a threaded build for anything, and
speed is the major reason to build unthreaded perl from the beginning.

IIRC the worst case difference was up to 40% loss (gcc + threads vs
native cc no-threads), where threads was the biggest problem.

--
H.Merijn Brand http://tux.nl Perl Monger http://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org/
http://qa.perl.org http://www.goldmark.org/jeff/stupid-disclaimers/

demerphq at gmail

Oct 8, 2009, 11:59 AM

Post #14 of 30 (954 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

2009/10/8 Curtis Jewell <lists.perl.perl5-porters [at] csjewell>:
> On Wed, 07 Oct 2009 10:26 -0700, "David E. Wheeler"
> <david [at] kineticode> wrote:
>> On Oct 7, 2009, at 10:24 AM, Rafael Garcia-Suarez wrote:
>>
>> > Even if we manage someone to fix threading, this will slow down
>> > sort(). Threading also has a non-negligeable performance impact on
>> > memory and speed of every perl program.
>> >
>> > I think we should advice people in INSTALL to build with threading
>> > only if they really need it, and tell OS vendors to disable threading
>> > on their system perls.
>>
>> Snow Leopard ships with a threaded Perl. Hell, I think Leopard did.
>> That cat might have left the bag.
>
> And Strawberry is threaded. �If I switched it to non-threaded now, I'd
> be stood up to a wall and shot by the Padre people (they require
> threading) among others.

Im inclined to say that a non-threaded win32 build is pretty close to broken.

Yves

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

SteveHay at planit

Oct 9, 2009, 12:24 AM

Post #15 of 30 (952 views)
Permalink

RE: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

demerphq wrote on 2009-10-08:
> 2009/10/8 Curtis Jewell <lists.perl.perl5-porters [at] csjewell>:
>> On Wed, 07 Oct 2009 10:26 -0700, "David E. Wheeler"
>> <david [at] kineticode> wrote:
>>> On Oct 7, 2009, at 10:24 AM, Rafael Garcia-Suarez wrote:
>>>
>>>> Even if we manage someone to fix threading, this will slow down
>>>> sort(). Threading also has a non-negligeable performance impact on
>>>> memory and speed of every perl program.
>>>>
>>>> I think we should advice people in INSTALL to build with threading
>>>> only if they really need it, and tell OS vendors to disable threading
>>>> on their system perls.
>>>
>>> Snow Leopard ships with a threaded Perl. Hell, I think Leopard did.
>>> That cat might have left the bag.
>> And Strawberry is threaded. �If I switched it to non-threaded now, I'd
>> be stood up to a wall and shot by the Padre people (they require
>> threading) among others.
> Im inclined to say that a non-threaded win32 build is pretty close to
> broken.
>

Why do you say that? I always used to use a non-threaded perl on Win32, and only switched to threaded when I had to because mod_perl-2 needs it. Even now I still don't enable PERL_IMPLICIT_SYS because I have no need for the fork() emulation, and prefer Perl's malloc() (which can't be enabled with PERL_IMPLICIT_SYS) to the CRT's version.

demerphq at gmail

Oct 9, 2009, 12:44 AM

Post #16 of 30 (946 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

2009/10/9 Steve Hay <SteveHay [at] planit>:
> demerphq wrote on 2009-10-08:
>> 2009/10/8 Curtis Jewell <lists.perl.perl5-porters [at] csjewell>:
>>> On Wed, 07 Oct 2009 10:26 -0700, "David E. Wheeler"
>>> <david [at] kineticode> wrote:
>>>> On Oct 7, 2009, at 10:24 AM, Rafael Garcia-Suarez wrote:
>>>>
>>>>> Even if we manage someone to fix threading, this will slow down
>>>>> sort(). Threading also has a non-negligeable performance impact on
>>>>> memory and speed of every perl program.
>>>>>
>>>>> I think we should advice people in INSTALL to build with threading
>>>>> only if they really need it, and tell OS vendors to disable threading
>>>>> on their system perls.
>>>>
>>>> Snow Leopard ships with a threaded Perl. Hell, I think Leopard did.
>>>> That cat might have left the bag.
>>> �And Strawberry is threaded. �If I switched it to non-threaded now, I'd
>>> be stood up to a wall and shot by the Padre people (they require
>>> threading) among others.
>> �Im inclined to say that a non-threaded win32 build is pretty close to
>> broken.
>>
>
> Why do you say that? I always used to use a non-threaded perl on Win32, and only switched to threaded when I had to because mod_perl-2 needs it. Even now I still don't enable PERL_IMPLICIT_SYS because I have no need for the fork() emulation, and prefer Perl's malloc() (which can't be enabled with PERL_IMPLICIT_SYS) to the CRT's version.

Ah well, then its just me. Anytime i used an unthreaded perl on
windows it was just pain.

Yves

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

jpl at research

Oct 9, 2009, 3:22 AM

Post #17 of 30 (950 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

David E. Wheeler noted:
> On Oct 7, 2009, at 11:25 PM, Rafael Garcia-Suarez wrote:
>
> >> Just to be sure: That advice is in the context of using Safe.pm,
> >> right? Or are there problems with sort() ourside safe compartments
> >> under threading as well? Are there any open bugs about them?
> >
> > No, sort is thread-unsafe as long as the sort function is custom (and
> > not XS, IIRC). That's basically because it's called in a super-fast
> > way, for speed. I think there are bugs, but can't find one rapidly.
>
> It seems to me that such bugs should be fixed as they're identified.
> Even if sorting becomes slower with threads, I'll take correct over
> fast any day.

I have never used threads, and I don't understand the details of
the problem caused by custom comparison routines, but I have
never let ignorance stand in the way of an opinion. Might it be
possible to put a global shared lock on the use of sort, so only
one thread at a time could be doing a sort? -- jpl

rgs at consttype

Oct 9, 2009, 3:37 AM

Post #18 of 30 (944 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

2009/10/9 John P. Linderman <jpl [at] research>:
> David E. Wheeler noted:
>> On Oct 7, 2009, at 11:25 PM, Rafael Garcia-Suarez wrote:
>>
>> >> Just to be sure: That advice is in the context of using Safe.pm,
>> >> right? �Or are there problems with sort() ourside safe compartments
>> >> under threading as well? �Are there any open bugs about them?
>> >
>> > No, sort is thread-unsafe as long as the sort function is custom (and
>> > not XS, IIRC). That's basically because it's called in a super-fast
>> > way, for speed. I think there are bugs, but can't find one rapidly.
>>
>> It seems to me that such bugs should be fixed as they're identified.
>> Even if sorting becomes slower with threads, I'll take correct over
>> fast any day.
>
> I have never used threads, and I don't understand the details of
> the problem caused by custom comparison routines, but I have
> never let ignorance stand in the way of an opinion. �Might it be
> possible to put a global shared lock on the use of sort, so only
> one thread at a time could be doing a sort? �-- jpl

That way you will deadlock if your sort subroutine wants to wait for
another thread. (OK, that's probably very unlikely).
IIRC, the problem comes from the fact that pp_sort modifies the
optree, which is shared among threads.

davem at iabyn

Oct 11, 2009, 5:35 AM

Post #19 of 30 (919 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Fri, Oct 09, 2009 at 12:37:15PM +0200, Rafael Garcia-Suarez wrote:
> That way you will deadlock if your sort subroutine wants to wait for
> another thread. (OK, that's probably very unlikely).
> IIRC, the problem comes from the fact that pp_sort modifies the
> optree, which is shared among threads.

Are you sure that's still the case? I thought that had been fixed ages
ago?

--
Dave's first rule of Opera:
If something needs saying, say it: don't warble it.

Tim.Bunce at pobox

Oct 30, 2009, 8:55 AM

Post #20 of 30 (802 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Sun, Oct 11, 2009 at 01:35:40PM +0100, Dave Mitchell wrote:
> On Fri, Oct 09, 2009 at 12:37:15PM +0200, Rafael Garcia-Suarez wrote:
> > That way you will deadlock if your sort subroutine wants to wait for
> > another thread. (OK, that's probably very unlikely).
> > IIRC, the problem comes from the fact that pp_sort modifies the
> > optree, which is shared among threads.
>
> Are you sure that's still the case? I thought that had been fixed ages
> ago?

Specifically in http://rt.perl.org/rt3/Public/Bug/Display.html?id=30333
I presume.

Tim.

Tim.Bunce at pobox

Nov 6, 2009, 2:43 AM

Post #21 of 30 (756 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Tue, Oct 06, 2009 at 12:55:47PM -0700, Tim Bunce via RT wrote:
> Any news of progress with this bug?
>
> Meanwhile, I have a workaround: explicitly share the globs for a and b. In other words, add *a
> and * b to the arguments of the share() method:
>
> $safe->share(qw(&debug *a *b));

To summarize the thread so far...
- it's confirmed that the bug is still present in 5.10.1.
- we digressed into a "don't use threaded perl" discussion
but that's not an option for many people these days.
- some workarounds are possible, but *none work* for calls to
sort() with custom sort subs in third-party code
in other packages e.g., CPAN modules.

Tim.

p.s. It was suggested that sort with custom sort subs isn't thread safe
anyway. If that's true then it's a very serious problem. It's covered
by RT#30333 (http://rt.perl.org/rt3/Public/Bug/Display.html?id=30333)
which is still marked Open. Yet I see tests for sort with a custom sub
in op/threads.t. Should RT#30333 be marked Closed?

If so, does that also fix RT#37508?
http://rt.perl.org/rt3/Public/Bug/Display.html?id=37508

ikegami at adaelis

Nov 6, 2009, 11:03 AM

Post #22 of 30 (758 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Fri, Nov 6, 2009 at 5:43 AM, Tim Bunce <Tim.Bunce [at] pobox> wrote:

> p.s. It was suggested that sort with custom sort subs isn't thread safe
> anyway. If that's true then it's a very serious problem. It's covered
> by RT#30333 (http://rt.perl.org/rt3/Public/Bug/Display.html?id=30333)
> which is still marked Open. Yet I see tests for sort with a custom sub
> in op/threads.t. Should RT#30333 be marked Closed?
>

I can't reproduce it with new versions of Perl.
The caused identified in RT#30333 was solved by
http://perl5.git.perl.org/perl.git/commit/9850bf21fc4ed69d8ddb0293df59411f891c62df

If so, does that also fix RT#37508?
> http://rt.perl.org/rt3/Public/Bug/Display.html?id=37508
>

I can't reproduce it with new versions of Perl.
The caused identified in RT#37508 was the same one identified in RT#30333.

I think both should be closed.
- Eric

badalex at gmail

Nov 6, 2009, 1:30 PM

Post #23 of 30 (747 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Fri, Nov 6, 2009 at 03:44, Tim Bunce via RT
<perlbug-followup [at] perl> wrote:
> On Tue, Oct 06, 2009 at 12:55:47PM -0700, Tim Bunce via RT wrote:
>> Any news of progress with this bug?
>>
> To summarize the thread so far...
> - it's confirmed that the bug is still present in 5.10.1.
> - we digressed into a "don't use threaded perl" discussion
> but that's not an option for many people these days.

Yes, and thanks for pointing out that the above really has nothing to
do with *this* bug. Its not running a sort with threads its just
broken with a threaded *build* of perl. :)

> - some workarounds are possible, but *none work* for calls to
> sort() with custom sort subs in third-party code

Um the last patch I posted should...
http://rt.perl.org/rt3/Ticket/Display.html?id=60374#txn-612980. And
while I found it quite ugly and im sure there are better ways to fix
this... (namely we could fix Opcode::_safe_call_sv to do something
similar, or fix it as diagnosed in
http://rt.perl.org/rt3/Ticket/Display.html?id=60374#txn-491794) I was
more or less looking for some kind of validation as to the approach
:).

People seemed to prefer to talk about how you should never be using a
threaded perl anyways... *shrug* Perhaps I should submit a patch to
disable -DUSETHREADS instead ?

badalex at gmail

Nov 7, 2009, 9:57 AM

Post #24 of 30 (746 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

[. Resend I replied but RT does not show it yet +20 hours and neither
does any perl5-porters list i can see ]

On Fri, Nov 6, 2009 at 03:43, Tim Bunce <Tim.Bunce [at] pobox> wrote:
> On Tue, Oct 06, 2009 at 12:55:47PM -0700, Tim Bunce via RT wrote:

> To summarize the thread so far...
> - it's confirmed that the bug is still present in 5.10.1.
> - we digressed into a "don't use threaded perl" discussion
> but that's not an option for many people these days.

Yes, and thanks for pointing out that the above really has nothing to
do with *this* bug. Its not running a sort with threads its just
broken with a threaded *build* of perl. :)

> - some workarounds are possible, but *none work* for calls to
> sort() with custom sort subs in third-party code

Um the last patch I posted should...
http://rt.perl.org/rt3/Ticket/Display.html?id=60374#txn-612980. And
while I found it quite ugly and im sure there are better ways to fix
this... (namely we could fix Opcode::_safe_call_sv to do something
similar, or fix it as diagnosed in
http://rt.perl.org/rt3/Ticket/Display.html?id=60374#txn-491794) I was
more or less looking for some kind of validation as to the approach
:).

But it seems RT never sent it anywhere... Mea culpa

badalex at gmail

Nov 7, 2009, 10:17 AM

Post #25 of 30 (745 views)
Permalink

Re: [perl #60374] Safe.pm sort {} bug with -Dusethreads [In reply to]

On Sat, Nov 7, 2009 at 10:57, Alex Hunsaker <badalex [at] gmail> wrote:
> Um the last patch I posted should...
> http://rt.perl.org/rt3/Ticket/Display.html?id=60374#txn-612980. And
> while I found it quite ugly

For reference here is said patch also find attached for the inevitable
gmail white space damage.

Subject: Fix ->reval('sub { sort { "$a" <=> "$b" } }')->() on usethreads

This is broken on usethreads builds because we only store the text of
the stash/package (i.e. main) in COP's. When the anon sub executes, it
then uses the stash name to look stuff up using the current (and wrong)
PL_defstash/PL_curstash. The non threaded case stores references so its
not an issue.

To fix this modify ->reval() to detect if we are returning an anon sub.
If so return an anon sub which calls _safe_call_sv(..., $real_anon_sub)
to setup the right PL_defstash and friends.

--

Safe.pm | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/ext/Safe/Safe.pm b/ext/Safe/Safe.pm
index ff099ec..e9c5dfa 100644
--- a/ext/Safe/Safe.pm
+++ b/ext/Safe/Safe.pm
@@ -2,6 +2,7 @@ package Safe;

use 5.003_11;
use strict;
+use Config qw(%Config);

$Safe::VERSION = "2.18";

@@ -289,7 +290,13 @@ sub reval {
my $root = $obj->{Root};

my $evalsub = lexless_anon_sub($root,$strict, $expr);
- return Opcode::_safe_call_sv($root, $obj->{Mask}, $evalsub);
+ my $ret = Opcode::_safe_call_sv($root, $obj->{Mask}, $evalsub);
+
+ if ($Config{usethreads} && ref $ret eq 'CODE') {
+ return sub { Opcode::_safe_call_sv($root, $obj->{Mask}, $ret) };
+ }
+
+ return $ret;
}

sub rdo {

Attachments:

safe_sort_threads.patch (1.28 KB)

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads