On Mon, Jul 11, 2011 at 7:57 AM, Luigi Ballabio <luigi.ballabio@gmail.com> wrote:
 
sub DESTROY {
   return unless $_[0]->isa('HASH');
   my $self = tied(%{$_[0]});
   return unless defined $self;
   delete $ITERATORS{$self};
   if (exists $OWNER{$self}) {
       QuantLibc::delete_Actual360($self);
       delete $OWNER{$self};
   }
}

The problem is in the last couple of instructions, or rather, in their
ordering.  First, the underlying C++ object is destroyed by the
QuantLibc::delete_Actual360 call.  Second, the wrappers try to delete
its entry in the $OWNER hash; but as far as I can see, to get the key
into the hash they try to get a string representation of $self, which in
turn tries to call the __str__ method on the already deleted object.
Hilarity ensues, in the form of a segmentation fault.

That is not correct; perl does not use your __str__ method to stringify $self.  Perl will create a valid string representation for $self -- without calling any underlying C++ methods -- even after the underlying C++ object has been deallocated.

My best guess is that you have a problem with object ownership.  Some method in your API returns a pointer, and SWIG is confused about whether the wrapped perl object "owns" the underlying C++ object.  SWIG does a good job with ownership semantics in the obvious cases (constructors, destructors); but if your API does anything non-obvious or bad (like deleting a C++ object when there is still a live perl object pointing to it), then you'll get segfaults.

Hope that helps.

Stefan
 

So, two questions:
1) the user that reported the problem suggested that an easy fix would
be to change SWIG so that the two instructions are generated in the
opposite order, that is, "delete $OWNER" first and
"QuantLibc::delete_Actual360" second.  Is this correct?  In this case,
the one-line patch I include should be enough.

2) Our __str__ method does not guarantee that two distinct instances
return different strings (which is fine for the other languages, since
the return values are just used as pretty-print representations.)  Is
this ok with the Perl machinery above (i.e., $self being used as a key
into $OWNER) or should we ensure unicity?

Thanks,
       Luigi


--

Present to inform, not to impress; if you inform, you will impress.
-- Fred Brooks


------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Swig-devel mailing list
Swig-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/swig-devel