develooper Front page | perl.wxperl.users | Postings from December 2010

Re: Crashy bug in either Wx or Perl 5.12

Thread Previous
From:
Mark Dootson
Date:
December 2, 2010 07:07
Subject:
Re: Crashy bug in either Wx or Perl 5.12
Message ID:
4CF7B5F7.6000306@znix.com
Eric,

I think I've misled you.
You can have multiple bits of PERL_MAGIC_ext and a method of identifying 
which bit you want is already there. Perl itself promises never to mess 
with PERL_MAGIC_ext. The docs suggest it is meant to be private to the 
extension using it. I think everything required is already in Perl.

The particular issue with wxPerl is that it uses the first member in 
PERL_MAGIC_ext that it finds - perfectly reasonably as a module writer 
might not expect an external extension to come along and mess with its 
private data. This could be fixed within wxPerl - so that wxPerl does 
get its own data despite Hash::Util::FieldHash.

Regards

Mark



On 02/12/2010 14:43, Eric J. Roode wrote:
>      Very interesting, Mark.
>      Long-term, I wonder if perhaps a change can be made to perl itself,
> to manage conflicting uses of PERL_MAGIC_ext.  So when an extension
> calls the macro or function to store its data in the variable's magic,
> perl tags it with something that identifies the extension, and files it
> as part of the data.  Then on fetching the data, perl looks up and
> returns only that extension's data.
>      Medium-term, perhaps perl could be modified to croak gracefully
> when someone stores data in PERL_MAGIC_ext when something's already
> there.  Ah, but then how could perl tell whether the extension is
> updating its own data or overwriting someone else's data?  You're left
> with tagging again.
>      Short-term, I think you're right -- wxperl should put a marker on
> its PERL_MAGIC_ext data, and croak gracefully when it reads data that it
> didn't put there.
> --
> Eric J. Roode
> On Wed, Dec 1, 2010 at 11:15 PM, Mark Dootson <mark.dootson@znix.com
> <mailto:mark.dootson@znix.com>> wrote:
>
>     Hi,
>
>     The code actually dies at '$self->InsertColumn(0, 'Zero');'
>
>     wxPerl uses PERL_MAGIC_ext to store a pointer to the underlying
>     wxWidgets C object data. This bit of 'magic' is supposed to be for
>     the use of extensions. (like wxPerl).
>
>     Hash::Util::FieldHash also uses the PERL_MAGIC_ext belonging to the
>     wxPerl extensions to store some data.
>
>     When '$self->InsertColumn(0, 'Zero');', the 'magic' that wxPerl
>     retrieves no longer points to the wxObject - but to the
>     Hash::Util::FieldHash data - so bad things happen.
>
>     This particular issue could probably be fixed. It is possible to
>     have multiple bits of magic of the same type - and wxPerl could add
>     an identifier for its own magic and only retrieve the PERL_MAGIC_ext
>     that has that identifier.
>
>     However, reading the Hash::Util::FieldHash pod, that talks of
>     calling the DESTROY method of referenced objects, amongst other
>     things. I would expect there to be more work needed to accommodate
>     Hash::Util::FieldHash than just fixing the 'magic' issue.
>
>     Hope this is useful info.
>


Thread Previous


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About