__NSAutoreleaseNoPool warnings on OSX

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Start DiscoveryAgent.searchServices, mostly like the example from
javadocs (in my case i was searching for 0x1101 - serial port services)

What is the expected output? What do you see instead?
Apple's JVM starts spitting warnings beginning with "__NSAutoreleaseNoPool"
See enclosed log file

What BlueCove version are you using (include build number for SNAPSHOT)? On
what operating system and jvm? Is this 64-bit or 32-bit OS and jvm?
Bluecove 2.1.0, Java 32-bit, Snow Leopard 10.6.2
java version "1.6.0_17"
Java(TM) SE Runtime Environment (build 1.6.0_17-b04-248-10M3025)
Java HotSpot(TM) Client VM (build 14.3-b01-101, mixed mode)

Please provide any additional information below.

After discovering the device and starting the service search the jvm starts
printing warning messages beginning with __NSAutoreleaseNoPool. From what i
read around the internet it seems to be an issue of spawning new threads
without the autorelease pool.

Original issue reported on code.google.com by lighteater on 13 Feb 2010 at 1:34

Attachments:

• logfile.txt

[GoogleCodeExporter]

However, this seems to have gone away.

I received these errors during the first week of August.   After some OS 
updates, I went looking for these messages so I could submit a patch.  Now I 
cannot see them.

I cannot see them using a 2.1 library (-d32).  I cannot see them using the 
latest from the repository (-d32, -d64)

Java(TM) SE Runtime Environment (build 1.6.0_20-b02-279-10M3065)
OS X 10.6.4

Original comment by shr...@gmail.com on 22 Aug 2010 at 2:47

[GoogleCodeExporter]

Are you sure? I still get them with the attached file.

The fix for this is relatively easy, but I'm not sure it's the right one.
I'll try to formulate the fix as a patch tomorrow, so it can be discussed.

An SDP query also triggers the bug, I'll attach a test case for that as well. 
No patch yet though.

Original comment by Botje.linux@gmail.com on 24 Aug 2010 at 4:10

Attachments:

• SDPQueryBug.java

[GoogleCodeExporter]

Okay. I kind of forgot about this, sorry :)

I discussed the issue with Apple engineering, who replied the following:

"""
Developers need to invoke their discovery calls on the AppKit main thread, 
using [NSObject performSelectorOnMainThread:::]. Also, if you start the AWT via 
Toolkit.getDefaultToolkit(), a default autorelease pool is created implicitly, 
and may be an acceptable workaround for this problem.

The IOBluetooth libraries are likely written around the assumption that they 
will only be used by the main AppKit thread (Thread 0). The Java AWT starts up 
the main AppKit thread implicitly, but if you want to run it yourself, you can 
use NSApplicationMain(). If you do need to start a Java AWT/Swing UI at some 
point later, running NSApplicationMain() yourself will present some challenges.
"""

The suggested workaround works, of course, but is hard to use in bluecove as it 
is a library. As I said earlier, I managed to silence the warnings produced 
when a bluetooth device is discovered but haven't managed to do the same for 
SDP stuff yet.

Original comment by Botje.linux@gmail.com on 14 Sep 2010 at 2:36

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I had the same problem. Adding Toolkit.getDefaultToolkit() to main() silenced 
all the messages, even though I was not even using AWT/Swing. 

Original comment by gostpa...@gmail.com on 7 Nov 2010 at 4:04

[GoogleCodeExporter]

I am having this same problem and I added Toolkit.getDefaultToolkit() to main 
with no results.  The NSAutoreleaseNoPool - just leaking errors persist.  Any 
idea what I'm doing wrong?  Am i supposed to do something with the toolkit this 
makes?

Original comment by MaJelli...@gmail.com on 15 Nov 2010 at 12:13

[GoogleCodeExporter]

It looks like the exactly same error I had when I try to execute 
StreamConnection connection = streamConnNotifier.acceptAndOpen();
The program crashes and shows the memory leaking error when the bluetooth 
device is trying to connect. 

Original comment by fengtso on 19 Nov 2010 at 1:34

[GoogleCodeExporter]

Any progress/update on this. With SNAPSHOT 2.1.1 on a MacBook Pro OS X 10.6.5 
(64 bit) I see the problem go away with the Toolkit.getDefaultToolkit() hack 
inserted into SDPQueryBug.java's main(). However, if I change the doDiscovery() 
method to use retrieveDevices and not the GIAC, i.e.

RemoteDevice[] rds = 
LocalDevice.getLocalDevice().getDiscoveryAgent().retrieveDevices(DiscoveryAgent.
CACHED);
          System.out.println("Found "+rds.length+" devices");

I get the autorelease problem right away. This is pretty annoying...

Original comment by ee.k...@gmail.com on 4 Jan 2011 at 4:23

Attachments:

• SDPQueryBug.java