Bug#779357: perl: Debugger hangs when threads are involved

Niko Tyni ntyni at debian.org
Mon Apr 13 18:38:50 UTC 2015


On Sun, Apr 12, 2015 at 12:10:28AM -0400, James McCoy wrote:
> Control: tag -1 patch
> 
> On Sat, Feb 28, 2015 at 08:01:58PM +0200, Niko Tyni wrote:
> > forwarded 779357 https://rt.perl.org/Public/Bug/Display.html?id=120170
> > thanks
> > 
> > On Fri, Feb 27, 2015 at 05:15:57PM -0500, James McCoy wrote:
> > 
> > > As an FYI, upstream commit cde405a6b is what caused "perl -dt" to be
> > > required.  Re-adding the lock prototype to the current perl5db.pl allows
> > > "perl -d" to at least start, but then the debugger errors out with
> > > "Modification of a read-only value attempted at .../perl5db.pl line
> > > 4129." which is this:
> > > 
> > >     # Save current single-step setting.
> > >     $stack[-1] = $single;
> > 
> > Thanks. I got that far too, and I also bisected the 'Modification of a
> > read-only value' thing to ce0d59fdd1c7d145efdf6bf8da56a259fed483e4
> > but that doesn't help much.
> 
> The attached patches are what I submitted upstream (Perl RT#124127).
> They get the debugger back to the pre-5.18 state (“perl -d” works
> again).

Thanks. I was aware of those and have been monitoring the ticket for
upstream review.

The only problem I have with the patches is that they seem more like a
workaround for some other problem: there's no reason why extending the
@stack array by modifying $#stack should create read-only elements AFAICS.

It's probably the same thing as this regression:

 % perl -Mthreads -le 'my @a = ("foo");  threads->create(sub { $#a=1; $a[1]="bar"; print @a})->join;'
 Thread 1 terminated abnormally: Modification of a read-only value attempted at -e line 1.

which (again) regressed with ce0d59fdd1c7d145efdf6bf8da56a259fed483e4.

I'll follow up with this on the upstream bug.
-- 
Niko Tyni   ntyni at debian.org




More information about the Perl-maintainers mailing list