Download it now!
Bug 31705 - Memory Leak and crash from unopkg Gui ?
Summary: Memory Leak and crash from unopkg Gui ?
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86 (IA32) Mac OS X (All)
: low minor
Assignee: Not Assigned
URL:
Whiteboard: (target:4.2.0)
Keywords:
Depends on:
Blocks:
 
Reported: 2010-11-18 02:01 UTC by Alex Thurgood
Modified: 2013-06-11 06:56 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
MacOS X log file for crash 31705, LOdev 2012-05-11 (41.87 KB, text/plain)
2012-05-11 06:30 UTC, Roman Eisele
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Thurgood 2010-11-18 02:01:11 UTC
Hi,


If the Extensions Manager Gui is started from the command line in Mac OSX SnowLeopard, then this message appears in the console on clicking on the "Close" button :

unopkg[5613:e07] *** __NSAutoreleaseNoPool(): Object 0x53335b0 of class RemoteControlContainer autoreleased with no pool in place - just leaking
2010-11-18 10:34:18.326 unopkg[5613:e07] *** __NSAutoreleaseNoPool(): Object 0x5333990 of class MultiClickRemoteBehavior autoreleased with no pool in place - just leaking



Alex
Comment 1 Alex Thurgood 2011-01-05 07:06:41 UTC
Same problem still present in LibO 3.3 beta 2.

Alex
Comment 2 Don't use this account, use tml@iki.fi 2011-01-05 07:13:30 UTC
If this message comes from the unopkg executable I would say it can be just ignored. That program runs for just a short while, doesn't it, and any leak is harmless.

Besides, "normal" users don't start LO from a command line, and will presumably thus not see this informational message.
Comment 3 Björn Michaelsen 2011-12-23 11:34:34 UTC
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 4 Roman Eisele 2012-05-11 06:22:55 UTC
Browsing through our MacOS X issues with NEEDINFO status, I stumbled over this report. Just for fun I tried if it still reproducible (in order to clear the status).

Surprise: it is not only still reproducible both with LibreOffice 3.5.3.2 and with the current Master/LOdev (Build ID: 9e536d2, 2012-05-11_06), there is also a crash now!

With Master/LOdev on MacOS X 10.6.8, the terminal output reads:

2012-05-11 15:01:22.642 unopkg[499:903] *** __NSAutoreleaseNoPool(): Object 0x5a83f50 of class NSCFString autoreleased with no pool in place - just leaking
2012-05-11 15:01:22.644 unopkg[499:903] *** -[NSAutoreleasePool release]: This pool has already been released, do not drain it (double release).
2012-05-11 15:01:22.644 unopkg[499:903] *** __NSAutoreleaseNoPool(): Object 0x2227820 of class RemoteControlContainer autoreleased with no pool in place - just leaking
2012-05-11 15:01:22.645 unopkg[499:903] *** __NSAutoreleaseNoPool(): Object 0x22277e0 of class MultiClickRemoteBehavior autoreleased with no pool in place - just leaking
Bus error

^This last line is new, and at the same time, MacOX tells me that LOdev crashed (EXC_BAD_ACCESS (SIGSEGV)). I will attach the MacOS X log file created for the crash.

Setting Status back to NEW because the issue is still reproducible.
Comment 5 Roman Eisele 2012-05-11 06:28:56 UTC
@Tor Lillqvist:
I don't know how important this issue is, I just wanted to check its status, and I agree to you (comment #2), that '"normal" users don't start LO from a command line'. So feel free just to ignore it ;-)

I have inserted you into CC just for the case that the (new) crash could be interesting and change the importance of the issue -- maybe it is the sign of some deeper problems or so, which can attract some attention ... Again, I don't know, I'm no developer, just a simple QA helper. Thanks!
Comment 6 Roman Eisele 2012-05-11 06:30:25 UTC
Created attachment 61451 [details]
MacOS X log file for crash 31705, LOdev 2012-05-11
Comment 7 Julien Nabet 2013-06-08 12:41:32 UTC
Roman/Alex: any improvement with 4.0 branch?
Comment 8 Alex Thurgood 2013-06-11 05:28:17 UTC
Hi Julien,


No message about leakage on the console anymore in 4.2 master. Closing as WFM.


Alex
Comment 9 Alex Thurgood 2013-06-11 05:29:31 UTC
Oh, and it doesn't crash either ;-)


Alex
Comment 10 Julien Nabet 2013-06-11 05:36:28 UTC
Alex: Indeed a crash which isn't reproducible anymore is "slightly" more important than the disappearance of a memory leak :-)
As you can see, I added target 4.2.0 (with parenthesis because there's no specific fix).
Just for information, have you seen the problem with 4.0.3 or 4.1.0 beta?
Comment 11 Alex Thurgood 2013-06-11 06:56:28 UTC
Hi Julien,

I don't see it with :

Version 4.0.3.3 (Build ID: 0eaa50a932c8f2199a615e1eb30f7ac74279539)


and I don't have a 4.1 beta around to test (yet), I've already got too many versions of LO floating around on my system as it is ;-)


Alex