338041 - _NSAutoreleaseNoPool(): Object x of class y autoreleased with no pool in place - just leaking (Cocoa icon decoder)

Status: RESOLVED WORKSFORME

(Core :: Graphics: ImageLib, defect)

Description

[Stefan [:stefanh]]

Mac OS 10.3.9, seamonkey 1.8 (20060514)branch (must be seen seen on trunk as well).

When I try to download a .dmg file and the download dialog box opens, I get a bunch of messages in console.log.

Sample:

2006-05-15 19:54:10.858 seamonkey-bin[487] *** _NSAutoreleaseNoPool(): Object 0x53547e0 of class NSCFString autoreleased with no pool in place - just leaking

2006-05-15 19:54:10.971 seamonkey-bin[487] *** _NSAutoreleaseNoPool(): Object 0x53c1940 of class NSCFString autoreleased with no pool in place - just leaking

2006-05-15 19:54:11.016 seamonkey-bin[487] *** _NSAutoreleaseNoPool(): Object 0x53ce4f0 of class NSImage autoreleased with no pool in place - just leaking

2006-05-15 19:54:11.021 seamonkey-bin[487] *** _NSAutoreleaseNoPool(): Object 0xa2e793cc of class NSCFString autoreleased with no pool in place - just leaking

2006-05-15 19:54:11.041 seamonkey-bin[487] *** _NSAutoreleaseNoPool(): Object 0x41105c0 of class NSCFString autoreleased with no pool in place - just leaking

2006-05-15 19:54:11.042 seamonkey-bin[487] *** _NSAutoreleaseNoPool(): Object 0xa2e7938c of class NSCFString autoreleased with no pool in place - just leaking

2006-05-15 19:54:11.045 seamonkey-bin[487] *** _NSAutoreleaseNoPool(): Object 0x53d0850 of class NSView autoreleased with no pool in place - just leaking

2006-05-15 19:54:11.053 seamonkey-bin[487] *** _NSAutoreleaseNoPool(): Object 0x53d0850 of class NSView autoreleased with no pool in place - just leaking

2006-05-15 19:54:11.088 seamonkey-bin[487] *** _NSAutoreleaseNoPool(): Object 0x53d12f0 of class NSImageCacheView

Comment 1

[Mark Mentovai]

We don't have a root pool when using Carbon widgets.  Objects autoreleased to the root pool will leak anyway, so the icon decoder should probably be a little more careful with memory management.

Comment 2

[Josh Aas]

I don't see these messages on a 1.8 branch debug build with the new icon decoder. I am on 10.4.6, so maybe Tiger doesn't show them. I don't doubt it is an issue though.

Comment 3

[Josh Aas]

Attachment: fix v0.9

This patch works if you manually copy the new header file into objdir/dist/include/widget. How do I change the widget/src/mac Makefile to do that automatically?

Comment 4

[Josh Aas]

Attachment: fix v1.0

Comment 5

[Josh Aas]

Attachment: fix v1.1 trunk

Comment 6

[Mark Mentovai]

Comment on attachment 222399 [details] [diff] [review]
fix v1.1 trunk

A few simple changes.

>Index: widget/src/mac/nsStAutoreleasePool.h

Needs a license block.

>+#include <Cocoa/Cocoa.h>

#import, not #include.

>+/*
>+ * If you are writing code that uses autoreleased objects and is not executed
>+ * inside of an event loop with an autorelease pool (other than the root
>+ * autorelease pool if one exists), then you can create an instance of this
>+ * class at the beginning of the function to get an autorelease pool and the
>+ * compiler will take care of releasing it.
>+ */

State also that this file must only be included by Objective-C++ (.mm) source.  (Note to readers who are not Josh: this isn't a problem because you don't ordinarily need your autorelease pools to be someplace where you're not getting autoreleased objects, i.e., in cocoa/objc.)

>+class nsStAutoreleasePool
>+{
>+public:
>+
>+  NSAutoreleasePool* mPool;

The member var should be private.  The ctor and dtor should be public.

>+  nsStAutoreleasePool()
>+    : mPool(nil)
>+  {
>+    mPool = [[NSAutoreleasePool alloc] init];
>+  }
>+  
>+  ~nsStAutoreleasePool()
>+  {
>+    [mPool release];
>+  }
>+  
>+};

>Index: modules/libpr0n/decoders/icon/mac/nsIconChannel.mm
> nsresult nsIconChannel::MakeInputStream(nsIInputStream** _retval, PRBool nonBlocking)
> {
>+  nsStAutoreleasePool aPool;

The "a" prefix usually means argument.  Maybe call it localPool?  If you're a fan of the indefinite, somePool?

>+  

Can you get rid of the whitespace on these blank lines, here and elsewhere?

Comment 7

[Josh Aas]

Attachment: fix v1.1.1 trunk

Comment 8

[Mark Mentovai]

Comment on attachment 222403 [details] [diff] [review]
fix v1.1.1 trunk

>Index: widget/src/mac/nsStAutoreleasePool.h
>+* The Original Code is mozilla.org code.

Guess so.

>+* The Initial Developer of the Original Code is
>+* Netscape Communications Corporation.

Who?

>+* Portions created by the Initial Developer are Copyright (C) 1998

When?

>+* Contributor(s):
>+*   Josh Aas <[e-mail]>

You got that right!

Comment 9

[Josh Aas]

I was following what happened in nsWindowMap.h which was created by Simon Fraser a year or two ago. Guess that was a bad idea :)

Comment 10

[Stuart Parmenter]

Comment on attachment 222403 [details] [diff] [review]
fix v1.1.1 trunk

imagelib shouldn't depend on widget.  just put the autoreleasepool stuff in both or put it in with the decoders.

Comment 11

[Marcia Knous [:marcia]]

I woke the Mac machine in the lab this AM, and Minefield crashed. The console was full of these types of errors:  1/29/09 9:35:45 AM firefox-bin[2659] *** _NSAutoreleaseNoPool(): Object 0x1abbf2c0 of class NSCarbonWindowContentView autoreleased with no pool in place - just leaking
)

Comment 12

[Mark E.]

I've got a few thousand of these messages, PPC OS X 10.5.8, unfortunately running FireFox and Namaroka and not sure from which it came, will try to sort that out, as well as if addons are playing a role:

1/24/10 11:14:54 AM firefox-bin[1301] *** _NSAutoreleaseNoPool(): Object 0x526fe20 of class NSCFNumber autoreleased with no pool in place - just leaking
Stack: (0x94b1cdac 0x94a49e14 0x963eaf04 0x2afbd3c 0x2aebe94 0x2a58338 0x2a585a8 0x2a97be8 0x2a99e6c 0x2a52178 0x2a51278 0x20a1b68 0x2a58338 0x2a585a8 0x2a97be8 0x2a99e6c 0x2a988c4 0x22c408c 0x20c58a8 0x20c3328 0x2a58338 0x2a585a8 0x2a97be8 0x2a9d83c 0x2a984e4 0x1eef60c 0x2ab2e34 0x1f041d4 0x1f08310 0x18b8e0 0x183758 0x18b03c 0x1364cc 0x13a0e8 0x1f4fef8 0x2ab2e34 0x1f041d4 0x1f08310 0x18b8e0 0x183758 0x18b03c 0x1337b4 0x1f4df38 0x1f4e7a4 0x2a9b690 0x2a9bea8 0x2a9c0c4 0x2a9c370 0x2a5d784 0x1eb6d64 0x1ebb650 0x3b80 0x28bc 0x25c0)

Comment 13

[Stefan [:stefanh]]

See also bug 541809, which probably is more relevent to the last comments (extension-related)

Comment 14

[Nomis101]

After starting my x86_64 Firefox build, I see in the console:

2010-03-29 01:35:27.736 firefox-bin[82871:903] *** __NSAutoreleaseNoPool(): Object 0x103105df0 of class NSThread autoreleased with no pool in place - just leaking
2010-03-29 01:37:28.414 firefox-bin[82899:903] *** __NSAutoreleaseNoPool(): Object 0x101f0c350 of class NSThread autoreleased with no pool in place - just leaking
2010-03-29 01:37:29.146 firefox-bin[82901:903] *** __NSAutoreleaseNoPool(): Object 0x102a241f0 of class NSThread autoreleased with no pool in place - just leaking

Comment 15

[Andreas H.]

Since 3.6.3 I also get lots of those leak warnings:

4/6/10 12:54:02 PM	firefox-bin[43396]	*** __NSAutoreleaseNoPool(): Object 0x17033770 of class NSCFArray autoreleased with no pool in place - just leaking
4/6/10 12:54:02 PM	[0x0-0x1e01e].org.mozilla.firefox	2010-04-06 12:54:02.447 firefox-bin[43396:903] *** __NSAutoreleaseNoPool(): Object 0x17033770 of class NSCFArray autoreleased with no pool in place - just leaking
4/6/10 12:54:02 PM	firefox-bin[43396]	*** __NSAutoreleaseNoPool(): Object 0x150d930 of class NSCFNumber autoreleased with no pool in place - just leaking
4/6/10 12:54:02 PM	[0x0-0x1e01e].org.mozilla.firefox	2010-04-06 12:54:02.449 firefox-bin[43396:903] *** __NSAutoreleaseNoPool(): Object 0x150d930 of class NSCFNumber autoreleased with no pool in place - just leaking
4/6/10 12:54:02 PM	firefox-bin[43396]	*** __NSAutoreleaseNoPool(): Object 0x1596df0 of class NSCFArray autoreleased with no pool in place - just leaking
4/6/10 12:54:02 PM	[0x0-0x1e01e].org.mozilla.firefox	2010-04-06 12:54:02.449 firefox-bin[43396:903] *** __NSAutoreleaseNoPool(): Object 0x1596df0 of class NSCFArray autoreleased with no pool in place - just leaking
4/6/10 12:54:02 PM	firefox-bin[43396]	*** __NSAutoreleaseNoPool(): Object 0xa001d428 of class NSCFString autoreleased with no pool in place - just leaking
4/6/10 12:54:02 PM	[0x0-0x1e01e].org.mozilla.firefox	2010-04-06 12:54:02.450 firefox-bin[43396:903] *** __NSAutoreleaseNoPool(): Object 0xa001d428 of class NSCFString autoreleased with no pool in place - just leaking
4/6/10 12:54:02 PM	firefox-bin[43396]	*** __NSAutoreleaseNoPool(): Object 0xa0019428 of class NSCFString autoreleased with no pool in place - just leaking
4/6/10 12:54:02 PM	[0x0-0x1e01e].org.mozilla.firefox	2010-04-06 12:54:02.450 firefox-bin[43396:903] *** __NSAutoreleaseNoPool(): Object 0xa0019428 of class NSCFString autoreleased with no pool in place - just leaking
4/6/10 12:54:02 PM	firefox-bin[43396]	*** __NSAutoreleaseNoPool(): Object 0xa001ca08 of class NSCFString autoreleased with no pool in place - just leaking

Comment 16

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Presumably the original issue this bug was filed about (nsIconChannelCocoa) is still there (as there's no pool in that file), but just being masked by the presence of the root pool in Cocoa widgets.

Nomis101, your leaks are likely bug 558489.

[e-mail], do you have AdBlock Plus or Google Toolbar installed?  If so, your leaks are probably bug 541809.  If not, you should file a new bug with some steps to reproduce that cause the leak messages to appear.

Comment 17

[Jonathan Kew [:jfkthame]]

(In reply to comment #16)
> Presumably the original issue this bug was filed about (nsIconChannelCocoa) is
> still there (as there's no pool in that file), but just being masked by the
> presence of the root pool in Cocoa widgets.

I just tried downloading a .dmg with a trunk build where the root pool has been removed, and did not get any autorelease-leakage warnings. If you think the issue is still present on trunk, please provide specific STR.

Comment 18

[Nomis101]

(In reply to comment #16)
> Nomis101, your leaks are likely bug 558489.
Yes, seems like this. 558489 is fixed and my console entries are gone.

Comment 19

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #17)
> I just tried downloading a .dmg with a trunk build where the root pool has been
> removed, and did not get any autorelease-leakage warnings. If you think the
> issue is still present on trunk, please provide specific STR.

I was basing that statement on the original analysis by mento and josh ("seeing the leaks in Carbon widgets, but they're covered up in Cocoa widgets by the root pool") and the fact nsIconChannelCocoa.mm hadn't had any pool added between 2006 and now, so if they're not showing up now, that's great (and we can WFM this bug).

Comment 20

[Joe Drew (not getting mail)]

sounds good to me :)

Comment 21

[Neville Hillyer]

I typically get the following Console message at each launch of SM 2.12.1:

16/09/2012 16:53:05 seamonkey[593] *** _NSAutoreleaseNoPool(): Object 0x111fd0 of class NSCFString autoreleased with no pool in place - just leaking
Stack: (0x97beadac 0x97b17e14 0x31afe4c 0x2577748 0x257a954 0x257afe0 0x257bd0c 0x257deb0 0x25e433c 0x25e6218 0x25e7798 0x23fec50 0x2400fc0 0x240438c 0x2404a68 0x24053a8 0x2405864 0x24062b0 0x24074c0 0x24084a4 0x2470434 0x29da750 0x2f7b9cc 0x2f7c630 0x3752bdc 0x2e0ae74 0x2e146c0 0x3b5f8d8 0x3b575e4 0x3b5f060 0x3b5fbd0 0x3b6004c 0x3ad9d00 0x2e05b90 0x2dff07c 0x3752a54 0x375341c 0x3752bdc 0x2e0ae74 0x2e146c0 0x3b5f8d8 0x3b575e4 0x3b5f060 0x3b5fbd0 0x3b6004c 0x3ad9d00 0x2e05b90 0x2dff07c 0x3752a54 0x375341c 0x2fb9704 0x2fb98d0 0x21fc5e4 0x2200870 0x2200d0c 0x3144 0x27c4)

Comment 22

[Neville Hillyer]

Sorry - I should have said I have http://code.google.com/p/seamonkey-ppc - is this the correct place to report its bugs?

Comment 23

[Ian Neal]

(In reply to Neville Hillyer from comment #22)
> Sorry - I should have said I have http://code.google.com/p/seamonkey-ppc -
> is this the correct place to report its bugs?

I would suggest - http://code.google.com/p/seamonkey-ppc/issues/list and click on the New Issue button.

Comment 24

[Neville Hillyer]

I looked at that but can see no history of bug reports there and I don't like Google's refusal to let me revert to my old password.

Comment 25

[Tony Mechelynck [:tonymec]]

(In reply to Neville Hillyer from comment #24)
> I looked at that but can see no history of bug reports there and I don't
> like Google's refusal to let me revert to my old password.

I can see four issues there. But I have Google groups opened in a few other tabs and Google Code tells me I'm logged in.

Comment 26

[Neville Hillyer]

I can see the issues but they don't appear to be bug reports.

Since Bugzilla appears to host some SM-PPC pages I don't see why it does not host its bugs.

Comment 27

[Tony Mechelynck [:tonymec]]

(In reply to Neville Hillyer from comment #26)
> I can see the issues but they don't appear to be bug reports.
> 
> Since Bugzilla appears to host some SM-PPC pages I don't see why it does not
> host its bugs.

Because any bugs in the code changes made to support PPC are not bugs in Mozilla code, and any bugs in the old Mozilla code to which they applied the changes are not bugs in _still supported_ Mozilla code.

Also, and maybe most important, the people who maintain the PPC ports don't search bugzilla.mozilla.org for bug reports about their product.

See also https://bugzilla.mozilla.org/page.cgi?id=etiquette.html