[SOLVED] error from juce_Font.cpp


#1

[EDIT] See below - it seems this strange behaviour was most likely due to not having a virtual destructor declared in a base class. blush

 

I am getting errors that seem to be related to Font, and using the malloc_error_break breakpoint in Xcode it seems to be coming from juce_Font.cpp at line 58:

juce_DeclareSingleton (TypefaceCache, false)​​

Its triggered from the first Label or TextEditor in a component that I am instantiating. 

No idea how to debug this further, or if theres a possibilty it might be a JUCE issue?

Its an intermittent error, sometimes does not occur. Usually after a successful run, upon stop and restarting the app again, the error will crop up again, or a different error, from line 484 of juce_mac_NSViewComponentPeer.mm:

            if (makeActiveWindow)

                [window makeKeyAndOrderFront: nil]; // <-- EXC_BAD_ACCESS here

            else

                [window orderFront: nil];

 

So suspect its some kind of memory thing. Any advice on how to debug this kind of error would be much appreciated. 


#2

Doubt if this is a bug in the underlying juce classes, or everybody would have similar problems. Maybe try cutting out bits of your own code until it works, to track down the culprit?


#3

Thanks, just wanted to check if it rings any bells with anyone. I've not had to delve into this kind of debugging before, but yes slimming down the code until I find the culprit sounds like the way to go. C++ is infuriating at times ! :)


#4

Think this was due to not having a virtual destructor in a base class. Also possibly to do with not calling deleteAndZero on a SafePointer.

Goes to show its worth putting time into learning the ins and outs of C++ as well as JUCE before diving in... 


#5

Isn't there a warning for this? -Wnon-virtual-dtor

Doesn't it get enabled by default in JUCE projects?


#6

It may well have been there, I didn't check. I've got into the bad habit of ignoring warnings due to the massive amount of warnings I've been getting from the STK library in my main project. Thanks for the heads up on that one. 


#7

Yeh, I hate it when 3rd party code throws up warnings. It's always best to disable warnings selectively for those you can't change so they don't clutter the output from your own code. This is quite easy to do if you package the 3rd party code into a JUCE module.