develooper Front page | perl.perl5.porters | Postings from April 2016

Re: [perl #127232] Storable -- segmentation fault

Thread Previous | Thread Next
Aaron Crane
April 24, 2016 11:59
Re: [perl #127232] Storable -- segmentation fault
Message ID:
My sincere apologies for the very long delay in this reply.

Ben Bullock via RT <> wrote:
> As bulk88 points out in his very informative post there are a number of different ways of making an object, but the method using IVs as described here:
> will inevitably lead to errors of this kind. Unless you can demonstrate that the above method of blessing a T_PTROBJ is illegal somehow according to the Perl specifications it seems to me that Storable should not be doing what it is doing.

For the record, I certainly don't think that T_PTROBJ and related
implementation techniques are invalid or inappropriate.

> The part which causes the segmentation fault is blessing the copy of the object into the class JSON::XS within Storable rather than the breaking encapsulation part, so I would suggest either not blessing objects into classes or giving the user responsibility for object serialization as described above. The method I described at the top, of making "secret" objects hidden behind a hash of random keys could just as easily be applied to a pure Perl module which would break Storable in a similar way, although without the segmentation fault errors.

This could certainly be made to work. However, I don't think it's
possible to change Storable's default behaviour here. Most Perl
classes are simple blessed hash refs, with all their data readily
visible to Storable; and users therefore expect to be able to use
Storable to store and retrieve such objects today, without doing
anything special. Changing this would certainly break large parts of
Storable's test suite, and my very strong expectation is that it would
also break large amounts of extant code that uses Storable.

Storable does already call classes' STORABLE_freeze and STORABLE_thaw
hooks when they're available (which I think counts as "giving the user
responsibility for object serialization" as you suggest). Would your
needs be met by giving Storable an option to have it refuse to
serialise and deserialise blessed references for classes without such
hooks? This would at least let code calling Storable opt in to
enforced delegation of responsibility for serialisation and

Aaron Crane **

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