OpenGL Dangling Pointer - Leaked Object

Linux
1

We have an OpenGLAppComponent as part of our software that is loaded into a viewport.
It is working without problems with OSX, but on Linux we get an leaked object:

*** Dangling pointer deletion! Class: DragAndDropContainer
JUCE Assertion failure in juce_LeakedObjectDetector.h:66

Apparently the leak originates from the linux? message queue, where it tries to trigger the openGL render loop after we already shut down the openGL context.
The openGL component gets deleted without any problems and after that the error occurs.
The leak detector proposes looking for multiple deletions, but we can’t find anything related to that.

kill 0x00007f71dea52187
juce::LeakedObjectDetectorjuce::DragAndDropContainer::~LeakedObjectDetector juce_LeakedObjectDetector.h:66
juce::DragAndDropContainer::~DragAndDropContainer juce_DragAndDropContainer.cpp:391
juce::LinuxComponentPeer::repaintOpenGLContexts juce_linux_X11_Windowing.cpp:2164
juce::LinuxComponentPeer::handleExposeEvent juce_linux_X11_Windowing.cpp:1959
juce::LinuxComponentPeer::handleWindowMessage juce_linux_X11_Windowing.cpp:1613
juce::WindowingHelpers::windowMessageReceive juce_linux_X11_Windowing.cpp:3381
juce::XWindowSystem::<lambda(int)>::operator()(int) const juce_linux_X11.cpp:217
juce::LinuxEventLoop::CallbackFunction<juce::XWindowSystem::initialiseXDisplay()::<lambda(int)> >::operator()(int) juce_linux_EventLoop.h:42
juce::InternalMessageQueue::dispatchNextEvent juce_linux_Messaging.cpp:121
juce::MessageManager::dispatchNextMessageOnSystemQueue juce_linux_Messaging.cpp:237
juce::MessageManager::runDispatchLoop juce_MessageManager.cpp:128
juce::JUCEApplicationBase::main juce_ApplicationBase.cpp:262
juce::JUCEApplicationBase::main juce_ApplicationBase.cpp:240
main main.cpp:47
__libc_start_main 0x00007f71dea34b97
_start 0x00005583b8079a6a

what is going on? :confused:

2

okay so I found the solution to our problem, but we don’t know why it works on linux that way…
so basically removing the openGL component triggered removing some cached image files of the openGL context and reset the shared_ptr to the openGL component also tried to remove the resources …
calling it in following order (with the discouraged to call method shutdownOpenGL) solved the issue:

cursorGL->shutdownOpenGL();
cursorGL.reset();
removeChildComponent(cursorGL.get());

On OSX it’s not necessary to call shutdownOpenGL() …

1 Like
3

are you sure OS X isn’t just eating the crash silently?

you’d think you’d need to always call shutdownOpenGL() regardless of platform…

per the docs:
https://docs.juce.com/master/classOpenGLAppComponent.html#a864b55311ef56455b0cc62a6afc67e7e

void OpenGLAppComponent::shutdownOpenGL	()	
This must be called from your subclass's destructor, to shut down the GL system and stop it calling render() before your class is destroyed.
1 Like
4

@matkatmusic I think you don’t understand the point. On OSX you should call shutdownOpenGL() inside the destructor, something like this:
~Destructor() { shutdownOpenGL(); }
If you do the same on Linux you become a leak, I observed this kind of behavior too. On Linux is necessary to call shutdownOpenGL() before you call the destructor.

5

ah ok. so the docs are wrong, and you possibly found a bug in that class, then?

6

@matkatmusic This is the point. [Here] you can see the OpenGL App Component tutorial (https://docs.juce.com/master/tutorial_open_gl_application.html)
Under the paragraph “Putting it all together” you are going to find, shutdownOpenGL() is placed at the destructor. As I said before, doing that on Linux caused a leak. The solution was presented over. This should be betted documented.