Apache OpenOffice (AOO) Bugzilla – Issue 68973
leaks: toolkit and destroying VCLXWindow
Last modified: 2013-02-07 21:59:28 UTC
Hi, while debugging Mac OS X native port's svdem with added FullScreen function for testing, I realized that VCLXWindow class leaks 48 bytes: Leak: 0x0313ffb0 size=48 0x06318348 0x00000001 0x027eb308 0x007e84ec .1.H.....~...~.. 0x00000000 0x00000000 0x00000000 0x00000000 ................ 0x00000000 0x00000000 0x0313fea0 0x00000003 ................ Call stack: [thread 2717]: | 0x0 | start | _start | sal_main | Main() | Application::Execute() | Application::Yield(bool) | AquaSalInstance::Yield(bool, bool) | SendEventToEventTarget | SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) | DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) | ToolboxEventDispatcherHandler(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) | HandleMouseEvent(OpaqueEventRef*) | HandleMouseEventForWindow(OpaqueWindowPtr*, OpaqueEventRef*, unsigned short) | SendEventToEventTarget | SendEventToEventTargetInternal(OpaqueEventRef*, OpaqueEventTargetRef*, HandlerCallRec*) | DispatchEventToHandlers(EventTargetRec*, OpaqueEventRef*, HandlerCallRec*) | HandleMouseUpDownEvent(OpaqueEventHandlerCallRef*, OpaqueEventRef*, void*) | ImplWindowFrameProc(void*, SalFrame*, unsigned short, void const*) | ImplHandleMouseEvent(Window*, unsigned short, unsigned char, long, long, unsigned long, unsigned short, unsigned short) | MenuBarWindow::ChangeHighlightItem(unsigned short, unsigned char, unsigned char, unsigned char) | MenuBarWindow::ImplCreatePopup(unsigned char) | PopupMenu::ImplExecute(Window*, Rectangle const&, unsigned long, Menu*, unsigned char) | MenuFloatingWindow::MenuFloatingWindow[in-charge](Menu*, Window*, long long) | FloatingWindow::FloatingWindow[not-in-charge](Window*, long long) | FloatingWindow::ImplInit(Window*, long long) | ImplBorderWindow::ImplBorderWindow[in-charge](Window*, long long, unsigned short) | ImplBorderWindow::ImplInit(Window*, long long, unsigned short, SystemParentData*) | Window::ImplInit(Window*, long long, SystemParentData*) | Window::IsTopWindow() const | Window::GetComponentInterface(unsigned char) | UnoWrapper::GetWindowInterface(Window*, unsigned char) | CreateXWindow(Window*) | VCLXWindow::VCLXWindow[in-charge]() | operator new(unsigned long) I think that the destructor of VCLXWindow is missing call to mpImpl->release(). Consider this as PATCH issue then ;-)
pl->fs: please have a look
Hmmm .... would be interested in a scenario for this. Do you have a chance testing whether the VCLXWindow in question is being disposed? The release call to mpImpl should happen in VCLXWindow::dispose, and I would have expected that every VCLXWindow is disposed finally (though, ~VCLXWindow is missing the safety-cleanup call to dispose).
fs: will try to collect some data for you tonight.
okay, simply opening the file menu already exposes the leak: The MenuFloatingWindow which is created then is destroyed upon closing the menu, but the respective VCLXWindow is never disposed, only destroyed. Normally, I'd say that ~VCLXWindow needs a if ( !mbDispose ) { acquire(); dispose(); } , which is the usual pattern for this case. However, I'm uncertain about the side effects - there might code behaving strangely if we do this. So, { ::vos::OGuard aGuard( GetMutex() ); if ( mpImpl ) { mpImpl->disposing(); mpImpl->release(); mpImpl = NULL; } } might be safer, though still leaking other instances (e.g. the A11Y potentially component associated with the window.) fs->cd: Your first AWT-issue? :)
cd: Accepted.
As there is no patch attached I change the type to "defect"
target 3.x