If I only call the constructors but no getter/setters, and I put a while(1){} at the end of Node.pl it doesn't happen, the script just "waits" (loops). So one thing that triggers it is global object destruction.

If I call set_parent($p), then an infinite loop, I notice that the destructor is triggered on the invocant $node (but not on $p). The malloc error doesn't happen. Note that the setter is not void: it returns the invocant. So there's a side effect to the conversion of the output in the typemap that makes a refcount drop to zero somewhere, triggering object destruction. However, a blessed reference to Node* is still returned.

If I call set_parent twice, the malloc error happens.

I can only conclude that this is due to some change that has taken place since 5.10 (all my Inline C stuff is still tied to that build); and you are going to need more expertise than I have to track down the cause.

---

With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority". I knew I was on the right track :)

In the absence of evidence, opinion is indistinguishable from prejudice.

I'm with torvalds on this Agile (and TDD) debunked I told'em LLVM was the way to go. But did they listen!

Subsequent to this new convention I have been doing some more computer programming and have come to learn that in (Safe)free()-ing variables there is a difference between ones that are "automatically" allocated and ones that are "dynamically" allocated. I am told that the difference is that the former are allocated on the stack, the latter on the heap. Apparently you can only free() dynamically allocated ones on the heap; doing it on the other ones triggers the error. I guess I am doing that inside the destructor. In any case, commenting out the Safefree makes the error go away, for better or worse.