Issue 68973 - leaks: toolkit and destroying VCLXWindow
Summary: leaks: toolkit and destroying VCLXWindow
Alias: None
Product: gsl
Classification: Code
Component: code (show other issues)
Version: 680m182
Hardware: All All
: P3 Trivial (vote)
Target Milestone: OOo 3.x
Assignee: AOO issues mailing list
QA Contact:
Depends on:
Reported: 2006-08-26 14:19 UTC by pavel
Modified: 2013-02-07 21:59 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description pavel 2006-08-26 14:19:48 UTC

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 ;-)
Comment 1 philipp.lohmann 2006-09-04 10:19:14 UTC
pl->fs: please have a look
Comment 2 Frank Schönheit 2006-09-04 10:29:02 UTC
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).
Comment 3 pavel 2006-09-04 12:45:52 UTC
fs: will try to collect some data for you tonight.
Comment 4 Frank Schönheit 2006-09-06 08:14:04 UTC
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 )
, 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.

    ::vos::OGuard aGuard( GetMutex() );
    if ( mpImpl )
      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? :)
Comment 5 carsten.driesner 2006-09-12 07:24:31 UTC
cd: Accepted.
Comment 6 Mathias_Bauer 2006-10-20 09:12:21 UTC
As there is no patch attached I change the type to "defect"
Comment 7 Mathias_Bauer 2008-01-11 09:37:17 UTC
target 3.x