In the past, I’ve noticed this is caused by issues in a deconstructor but I honestly don’t know when the problem started or where to start looking.
A lot of the time this happens because you’re leaking memory (or deleting something twice). Are you following RAII patterns, or are you being cavalier with allocation? (lots of calls to new/delete)
Yes, just attach the debugger to the running process and call quit. So the debugger would show you, where exactly the problem occurred.
It is unlikely a leak, since those are usually silently ignored. The whole processes memory will be freed anyway (still bad practice to leak, and it should be resolved).
So it sounds more like stuff became dangling while unrolling the stack…
Gotcha. I used the debugger in Xcode and closed the program. I traced it back from the line where it failed and saw that in my PluginEditor.cpp, it was complaining about my sliderAttachment unique pointers. I added .remove() on those unique pointers in the deconstructor and that fixed the problem. That seems odd to me though…because I don’t remember that being a problem before and I thought the point of smart pointers was that you don’t have to remember to delete them. Oh well, it’s fixed. Ha.
Yes, they should work like that. Maybe it’s some kind of order of declaration issue that you got the crash?
That crash is a classic:
Class members are constructed in the order of appearance in the class declaration and destroyed in the opposite order (what @Xenakios hinted in his post).
If you make sure to declare the Slider BEFORE the SliderAttachment you are safe from that crash, no code necessary. But I also like this suggestion from @yfede:
Oh wow. That method looks great. I’ll give it a shot when I get the chance, thanks.
Yep, that was it, haha. I changed the order that they were declared and I no longer needed to do the .remove()