in reply to Re^5: Inline::C self-referential struct idioms and memory
in thread Inline::C self-referential struct idioms and memory

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.

  • Comment on Re^6: Inline::C self-referential struct idioms and memory

Replies are listed 'Best First'.
Re^7: Inline::C self-referential struct idioms and memory
by BrowserUk (Patriarch) on Sep 04, 2015 at 20:45 UTC

    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!
[reply]

      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.

[reply]
        Apparently you can only free() dynamically allocated ones on the heap

        AIUI, when you create using Newx(), you are allocating dynamically - and you'll leak memory if you don't Safefree() those dynamically allocated variables when they go out of scope.

        Incidentally, DESTROY() doesn't have to be a perl sub.
        You could dispense with that perl sub and place it in the C code as something like (untested): 
        void DESTROY(Node* self) {
    warn("destroying self");
    Safefree(self);
}

        [download]
        However, you may well find that there are additional things to Safefree (again untested): 
        void DESTROY(Node* self) {
    warn("destroying self");
    Safefree(self-> parent);
    Safefree(self-> sv);
    Safefree(self);
}

        [download]
        Admittedly, you've then lost the identification of the actual object that's being Safefree'd - though I think that could be easily addressed.
        And I'm not sure how the self-referential nature of the Node object impacts upon things.

        Cheers,
        Rob
[reply]
[d/l]
[select]
[reply]

In Section Seekers of Perl Wisdom