Tim Bunce (tim...@pobox.com)

User Information

Display Name:

Tim Bunce

Partial Email Address:

tim...@pobox.com

Posts:

343	total
2	in Class::DBI
13	in DBIx::Class
1	in dbix-class@lists.scsys.co.uk
307	in Perl 5 Porters
3	in PostgreSQL - General
17	in PostgreSQL - Interfaces

5 Most Recent

All Posts

1) Tim Bunce Re: [perl #72942] Can't perform unicode operations in Safe compartment

+1 vote

Here's the patch. Tim.

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

On Fri, Feb 19, 2010 at 05:25:33AM -0800, Tim Bunce wrote:
> 
> Basic operations on unicode strings don't work inside a Safe compartment:
> 
> perl -MSafe -MOpcode=full_opset -e '$a=Safe->new; $a->permit(full_opset()); $a->reval(q{ pack("U",0xC4) =~ /\\xE4/i; 1 }) or die $@ '
> Undefined subroutine Safe::Root0::utf8::SWASHNEW called at (eval 5) line 1

> On reflection though, I think it would be better for Safe to simply *always*
> require utf8 (and ensure utf8_heavy.pl is run) so it can always share
> utf8::SWASHNEW. That's not only cleaner because it hides the implementation
> details of perl unicode, but it also fixes the PostgreSQL problem.
> 
> I'll followup this post with a patch that does that.

Here's the patch.

Tim.

Attachment:Safe-2.22a-swashnew1.patch

2) Tim Bunce Re: Failures with bleadperl and NYTProf

+1 vote

Devel::NYTProf depends on JSON::Any. JSON::Any will prefer JSON::XS and then JSON over JSON::DWIW,...

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

On Tue, Feb 16, 2010 at 08:40:09AM +0100, H.Merijn Brand wrote:
> On Mon, 15 Feb 2010 18:08:00 -0600, Steve Peters
> <steve@fisharerojo.org> wrote:
> 
> > I've been doing some testing with bleadperl and ran into some bad
> > results with NYTProf.  Specifically, t/50-errno.t causes a
> > segmentation fault on MAC OS X.  I compiled my bleadperl with -des
> > -Dusedevel -Duseithreads.  Just wanted to see if anyone else had run
> > into this while I start digging to see if I can reproduce on other
> > OS's.
> 
> On a side note: Devel::NYTProf depends on JSON::DWIW, which is not C89
> compliant, and thus won't build on C89 compilers.

Devel::NYTProf depends on JSON::Any. JSON::Any will prefer JSON::XS and then
JSON over JSON::DWIW, so I think C89 isn't a significant issue for NYTProf.

Hopefully JSON::DWIW will be fixed soon anyway
https://rt.cpan.org/Public/Bug/Display.html?id=50302

Tim.

3) Tim Bunce Re: [develnytprof-dev: 1672] Failures with bleadperl and NYTProf

+1 vote

I ran into it recently. That's what led me to file this perlbug the other day:...

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

On Mon, Feb 15, 2010 at 06:08:00PM -0600, Steve Peters wrote:
> I've been doing some testing with bleadperl and ran into some bad
> results with NYTProf.  Specifically, t/50-errno.t causes a
> segmentation fault on MAC OS X.  I compiled my bleadperl with -des
> -Dusedevel -Duseithreads.  Just wanted to see if anyone else had run
> into this while I start digging to see if I can reproduce on other OS's.

I ran into it recently. That's what led me to file this perlbug the
other day:
http://rt.perl.org/rt3/Public/Bug/Display.html?id=72850

It seems to be related to setting $! to a large (or negative) value.

(For the NYTProf test I've simply changed it to use a smaller value.
I'll check that in soon.)

Tim.

4) Tim Bunce Re: [perl.git] branch blead, updated. v5.11.4-78-g2630fd9

+1 vote

Adding a $SIG{__WARN__} hook to hide the (currently unavoidable) warning seems like a reasonable...

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

On Thu, Feb 11, 2010 at 01:43:50PM -0500, Jerry D. Hedden wrote:
> On Thu, Feb 11, 2010 at 05:32, Rafael Garcia-Suarez
> <rgarciasuarez@gmail.com> wrote:
> > In perl.git, the branch blead has been updated
> >
> > <http://perl5.git.perl.org/perl.git/commitdiff/2630fd9e8e31d2fd409e2e8ec16dc85d230a3eb3?hp=78c4a74a09b8f7ed410a879bd78dfb83cbf7861c>
> >
> > - Log -----------------------------------------------------------------
> > commit 2630fd9e8e31d2fd409e2e8ec16dc85d230a3eb3
> > Author: Tim Bunce <Tim.Bunce@pobox.com>
> > Date:   Thu Feb 11 11:29:17 2010 +0100
> >
> >    Bug in Safe 2.21 re propagating exceptions
> >
> >    An exception thrown from a closure gets lost.
> >    I've boiled it down to this:
> >
> >       perl -MSafe -e 'Safe->new->reval(q{sub { die @_ }})->(qq{ok\n})'
> >
> >    That should die with "ok".
> >
> >    The problem is that the closure that wraps any returned code ref if
> >    threads are enabled is acting as an eval block so hiding the exception.
> > -----------------------------------------------------------------------
> 
> This is causing the following anomoly in 'make test':
> 
> dist/Safe/t/safesort...........................................	(in
> cleanup) died
> ok

Adding a $SIG{__WARN__} hook to hide the (currently unavoidable) warning
seems like a reasonable thing to do.

Tim.

5) Tim Bunce Re: Bug in Safe 2.21 (or Opcode) re propagating exceptions

+1 vote

I've attached a more complete patch. Rafaël, I think this is ready to apply and release as Safe...

Perl 5 Porters

[ Profile | Reply to group ]

[ Flat Thread Threaded ]

On Wed, Feb 10, 2010 at 04:38:58PM +0000, Tim Bunce wrote:
> On Tue, Feb 09, 2010 at 02:44:57PM +0000, Nicholas Clark wrote:
> > On Tue, Feb 09, 2010 at 02:41:44PM +0000, Tim Bunce wrote:
> > > On Mon, Feb 08, 2010 at 04:38:48PM +0000, Tim Bunce wrote:
> > > > In the context of PostgreSQL PL/Perl, which uses Safe, David Wheeler
> > > > pointed me to a bug in Safe 2.21. The effect is that an exception thrown
> > > > from a closure gets lost.
> > > > 
> > > > I've boiled it down to this:
> > > > 
> > > >     perl -MSafe -e 'Safe->new->reval(q{sub { die @_ }})->(qq{ok\n})'
> > > > 
> > > > That should die with "ok" but doesn't on 5.10.1 or 5.11.4 or 5.8.6.
> > > > It does die, correctly, on a whole bunch of other versions I have
> > > > lying around locally.
> > > > 
> > > > This is a heads up as I'm starting to dig. Any thoughts most welcome...
> > > 
> > > Turns out to be a threads issue. Fails with USE_ITHREADS, passes otherwise.
> > > (I had a mix of perl lying around with various configs.)
> > > 
> > > Still digging...
> > 
> > git bisect is probably your friend.
> > 
> > There's a section describing how to do it in perlrepository.pod:
> > 
> > http://perl5.git.perl.org/perl.git/blob/0972ecdf:/pod/perlrepository.pod#l626
> 
> Thanks. But I din't think a bisect will be helpful here.  Safe 2.20+
> fails for all perl versions (with threads enabled) that I've tried it on.
> 
> The problem is that the closure that wraps any returned code ref if
> threads are enabled is acting as an eval block so hiding the exception.
> 
> This mostly fixes it:

I've attached a more complete patch.

Rafaël, I think this is ready to apply and release as Safe 2.22.
(Which should then be inclded in 5.11.5.)

> One remaining problem is that G_KEEPERR 'helpfully' generates a warning.
> Per perlcall docs:
> 
>     In addition, a warning is generated using the appended string.
>     This can be disabled using "no warnings 'misc'".
> 
> I tried adding no warnings 'misc' in various places by I couldn't
> silence it. Any thoughts?

It looks like there isn't a good simple fix for this. The warning comes
from Perl_die_where(). So the prefix is added in, and controlled-by, the
lexical context that threw the exception - outside the control of this code.

Seems like G_KEEPERR is conflating separate issues :( Perhaps there's a
need for a G_KEEPERR_BUT_DONT_WARN, though that won't help existing perls.

Tim.

Attachment:safe-2.21-rethrow.patch

Highlight

Profile | Posts (343)

Home > People > Tim Bunce