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
Same problem still present in LibO 3.3 beta 2.
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.
[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:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
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 188.8.131.52 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
^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.
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!
Created attachment 61451 [details]
MacOS X log file for crash 31705, LOdev 2012-05-11
Roman/Alex: any improvement with 4.0 branch?
No message about leakage on the console anymore in 4.2 master. Closing as WFM.
Oh, and it doesn't crash either ;-)
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?
I don't see it with :
Version 184.108.40.206 (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 ;-)