Skip Menu |
 

This queue is for tickets about the Syntax-Feature-Try CPAN distribution.

Report information
The Basics
Id: 110073
Status: open
Priority: 0/
Queue: Syntax-Feature-Try

People
Owner: Nobody in particular
Requestors: EDAVIS [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: 1.002
Fixed in: (no value)



Subject: Segmentation fault, for the record
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Message-ID: <rt-4.0.18-5091-1449239393-371.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 341
Download (untitled) / with headers
text/plain 341b
On my system (Fedora 23) this script gives a segmentation fault. So far I have not been able to narrow it down further. I post it here for the record and to see if you can reproduce it. use syntax 'try'; foreach (2, 3, 4) { try { die "odd\n" if $_ % 2; } catch ($err) { next; } warn "got here $_\n"; }
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-5091-1449239393-371.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-5091-1449239393-371.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-26716-1449239536-1384.110073-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 307
Download (untitled) / with headers
text/plain 307b
Actually, here is a slightly reduced test case: $Carp::Internal{ 'Devel::Declare' } ||= 1; BEGIN { require 'Syntax/Feature/Try.pm'; return Syntax::Feature::Try->install; } foreach (2, 3, 4) { try { die "odd\n" if $_ % 2; } catch ($err) { next; } warn "got here $_\n"; }
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-26716-1449239536-1384.110073-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-5091-1449239393-371.0-0-0 [...] rt.cpan.org> <rt-4.0.18-26716-1449239536-1384.110073-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-11814-1449239992-1221.110073-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 733
Download (untitled) / with headers
text/plain 733b
last,redo,next (loop constrolls) are not supported inside try/catch/finally blocks. See documentation: http://search.cpan.org/~tnt/Syntax-Feature-Try-1.002/lib/Syntax/Feature/Try.pm#CAVEATS Do not call "next" inside "catch" block. Use some workaround: - use local variable and call "next" outside. - or use perl "eval" instead of try/catch. Dne Pá 04.pro.2015 09:32:16, EDAVIS napsal(a): Show quoted text
> Actually, here is a slightly reduced test case: > > $Carp::Internal{ 'Devel::Declare' } ||= 1; > BEGIN { require 'Syntax/Feature/Try.pm'; return Syntax::Feature::Try-
> >install; }
> foreach (2, 3, 4) { > try { > die "odd\n" if $_ % 2; > } > catch ($err) { > next; > } > warn "got here $_\n"; > }
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-11814-1449239992-1221.110073-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-5091-1449239393-371.0-0-0 [...] rt.cpan.org> <rt-4.0.18-26716-1449239536-1384.110073-0-0 [...] rt.cpan.org> <rt-4.0.18-11814-1449239992-1221.110073-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-28491-1449498195-144.110073-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 257
Download (untitled) / with headers
text/plain 257b
Thanks. Is there something that can be done to fail more safely if next is called inside a catch block? To die with a clear message rather than possibly segfault? Is it possible that 'next LABEL' might be made to work even if plain 'next' is unsupported?
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-28491-1449498195-144.110073-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-5091-1449239393-371.0-0-0 [...] rt.cpan.org> <rt-4.0.18-26716-1449239536-1384.110073-0-0 [...] rt.cpan.org> <rt-4.0.18-11814-1449239992-1221.110073-0-0 [...] rt.cpan.org> <rt-4.0.18-28491-1449498195-144.110073-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-27841-1449516279-960.110073-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 483
Download (untitled) / with headers
text/plain 483b
On 2015-12-07 09:23:15, EDAVIS wrote: Show quoted text
> Thanks. Is there something that can be done to fail more safely if > next is called inside a catch block? To die with a clear message > rather than possibly segfault? > > Is it possible that 'next LABEL' might be made to work even if plain > 'next' is unsupported?
There's more perl diagnostics when running the first example script with 5.23.5: $ perl5.23.5 /tmp/try.pl got here 2 got here 4 panic: av_extend_guts() negative count (-8).
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-28491-1449498195-144.110073-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-5091-1449239393-371.0-0-0 [...] rt.cpan.org> <rt-4.0.18-26716-1449239536-1384.110073-0-0 [...] rt.cpan.org> <rt-4.0.18-11814-1449239992-1221.110073-0-0 [...] rt.cpan.org> <rt-4.0.18-28491-1449498195-144.110073-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-21217-1449653252-1745.110073-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 550
Download (untitled) / with headers
text/plain 550b
Dne Po 07.pro.2015 09:23:15, EDAVIS napsal(a): Show quoted text
> Thanks. Is there something that can be done to fail more safely if > next is called inside a catch block? To die with a clear message > rather than possibly segfault?
I'am not sure how to detect if "next" is called inside this block (or subroutine). because try/catch block are internally converted to anonymous subroutine and then perl throws warning "Exiting subroutine via next ..." Show quoted text
> Is it possible that 'next LABEL' might be made to work even if plain > 'next' is unsupported?
I don't know.
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-5091-1449239393-371.0-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-4.0.18-5091-1449239393-371.0-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-6204-1450196821-550.110073-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 234
Download (untitled) / with headers
text/plain 234b
Do you think that the segmentation fault with try.pl indicates a bug either in the Syntax::Feature::Try XS code or in perl itself? Or do you think that since 'next' is not supported, the resulting perl interpreter crash is not a bug?


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.