develooper Front page | perl.perl5.porters | Postings from December 2013

Re: [perl #119801] Modifying @DB::dbline entries can crash perl

Thread Previous | Thread Next
Reini Urban
December 25, 2013 18:33
Re: [perl #119801] Modifying @DB::dbline entries can crash perl
Message ID:
On Wed, Oct 30, 2013 at 11:29 PM, Father Chrysostomos via RT
<> wrote:
> On Mon Oct 28 22:02:51 2013, sprout wrote:
>> On Mon Sep 16 23:53:11 2013, sprout wrote:
>> > How about having an array shared between threads and indexed by cop_seq?
>> >
>> > Or, if that makes the array too long, extend the struct for dbstate ops
>> > and store a separate sequence number.
>> >
>> > When the op is freed, it can invalidate its entry.  We would need three
>> > values: 0 = no op available, 1 = no breakpoint, 2 = breakpoint set.
>> >
>> > The numeric values stored in @DB::dbline elements would be indices into
>> > that breakpoint array.
>> Please review the attached patch, which is also on the sprout/dbline branch.
> In particular, does B::C need to access the extra fields that dbstate ops now have, or can we keep the cop–dbop distinction private?

Sorry, just saw this today.

No, B::C doesn't need to access private dbstate fields, since this is
an unsupported and unlikely usecase. One doesn't dump being-debugged
code into C, only fresh code.

However, Enbugger has a problem. A dummy nextstate field would be
better to have the same memory layout.
Reini Urban

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About