I’m working on MacOS 10.4 with XCode 2.4 and JUCE 1.45.
I am sure jasserts were causing the debugger to break when one was encountered, but since some time this doesn’t happen any more, although the debug console shows a line saying that the assert has been triggered and the file and line.
What could I possibly have done to disable this behaviour and, more important, how can I make the debugger to break on jasserts again?
Thanks to anyone who can help.
You might need to explicitly set the DEBUG=1 or NDEBUG=1 macros in your project if they’re not already there?
DEBUG=1 is defined in Debug configurations for both JUCE project and my own one, while for Release configurations the define is NDEBUG=1
I checked which version of juce_breakDebugger is compiled in by brutally adding a #error directive at the crucial point, and can say for sure that it resolves to a call to Debugger();
I’m not really into mac programming, so does this give some more clues to what my problem could be?
make sure you’re actually linking to the juce debug lib? I don’t know, but a quick breakpoint will surely make it obvious what’s going on?
I am having this problem, and it’s making me crazy!
I use the introjucer to create a project, and I then work on that project in XCode4. Everything goes smoothly, but my asserts simply show up in the debug output [“oh! this happened! bye!!”] and don’t break for me. I would love to know why!
Yeah, I just upgraded to Xcode 4 this week and hit the same thing! Looks like the old Debugger() command just doesn’t work any more in Xcode 4, so I replaced it yesterday with a normal assert (false).
My code seems to get ‘stuck’ on that assert false sometimes now (on XCode 4). I get there in the debugger, but can’t continue.
Bruce
[quote=“Bruce Wheaton”]My code seems to get ‘stuck’ on that assert false sometimes now (on XCode 4). I get there in the debugger, but can’t continue.
Bruce[/quote]
Yes, I’ve seen that too, but no idea why. I don’t think there’s much I can do about it, it seems like an Xcode 4 foible.
It’s a bit of a pain. I have what juce thinks is leaks on shut-down (I can’t see how, and I chip away at the problem every now and again) so I hit this every time I shut down.
I also have some ‘undesirable situation’ asserts which fire in debug mode sometimes.
How would I disable the assert enough to not whack Xcode?
Bruce
Do you have objects with static storage duration (i.e. globals) and non-trivial constructors?
I don’t think any globals, no.
I have a master ‘controller’ class and a comandmanager, but they are created in a standard juce main and exposed via an extern in a common header file.
Unless the leak detector fires before the main shutdown()?
Anyway, define ‘non-trivial’ in this case?
Bruce
The Juce leak detector makes use of class objects with static storage duration, that have non-trivial constructors and destructors. The destructors for all leak detector objects are called after main() returns, by code that the linker and compiler work together to call. In MSVC this is done through an ‘atexit’ hook and a special function.
So no, the leak detector does not fire before shutdown().
from What is a non-trivial constructor in C++? - Stack Overflow
[quote]
For a default constructor and destructor being “trivial” means literally “do nothing at all”. For copy-constructor and copy-assignment operator, being “trivial” means literally “be equivalent to simple raw memory copying” (like copy with memcpy).[/quote]
Consider the following simplified example:
MemoryBlock block (1024);
int main (int, char**)
{
return 0;
}‘block’ is a leak checked object with a non trivial destructor. Since it has static storage duration, its destructor is called after main returns. The problem with this code is that the C++ standard does not define the order of destructor calls to objects with static storage duration from different translation units. Since the Juce leak checking code for MemoryBlock goes into juce_MemoryBlock.obj (or something like that) instead of main.obj, the order of destruction is undefined.
One solution is to avoid objects with static storage duration that have non trivial destructors (specifically, objects that are derived and/or composed of leak-checked classes).
My solution was to fork my own version of the leak checker that works together with my own framework for reference counted singletons, and require that all objects with static storage duration and non trivial ctor/dtors get put into such a singleton.
Couldn’t see anything that seems to fit that description… most everything is per class. So I looked at Singletons, and one is being re-created after I shut it off, that led me to an instance still running a thread. I’ll try to fix that, although I don’t see where it relates back to the reported links.
Juce singletons have static storage duration and non-trivial destructors.