develooper Front page | perl.perl5.porters | Postings from March 2001

Re: my purify runs with 5.6.1-to-be

Thread Previous | Thread Next
Vadim Konovalov
March 16, 2001 14:32
Re: my purify runs with 5.6.1-to-be
Message ID:
> > Nope, and I probably won't for 5.6.1.  This bug is too low priority
> > to risk applying without understanding why it crashes only in some
> > places.
> Agreed.  reset() is pretty esoteric, even more esoteric that someone
> combines if (0) with it.

No! "if(0)" is not necessary to reproduce the crash -- any freeing of PMOP
is dangerous, because it's concept is currently broken - that list have no
right head. "reset" is is the only (IMHO) function which walks through the
list of PMOP's, and causes core dump when it's broken.

Following (without if(0)):

use strict;
sub new_pmop($) {
  my $pm = shift;
  return eval "sub {shift=~/$pm/}";
new_pmop "abcdef"; reset;
new_pmop "abcdef"; reset;
new_pmop "abcdef"; reset;
new_pmop "abcdef"; reset;

crashes 5.6.0 for Win32, both BorlandC++-compiled perl and ActiveState's
If it does not crashes on your system, then insert a couple more new_pmop
calls, a couple of innocent memory allocations, and you'll see a crash --
memory corruption is not a stable thing.

I can't right now create sample of a script that crashes without "reset",
but, as far as freeing of PMOP is not safe, a couple of allocating and
freeing of PMOPs in current implementation will cause a core dump.

As latest thing, currently freeing PMOPs breaks their chain, and this can
cause additional memory leaks.

Freeing of PMOP needs fixing.

Best wishes,
<!ENTITY Vadim REALLIFE "St.Petersburg, Russia">

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