For reference, I threw some extra pool management into glib2 to stop messages exactly like that here:
https://github.com/macports/macports-ports/blob/master/devel/glib2/files/patch-glib2-findfolders-before-Lion.diff perhaps adding some into openjdk would help. A bit of trial and error might be required. K > On Jul 16, 2024, at 7:44 AM, Ken Cunningham <ken.cunningham.web...@gmail.com> > wrote: > > The usual equivalent older construct is this: > > > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > { > > } > [pool drain]; > > > which (AFAIK) does exactly the same thing as: > > @autoreleasepool > { > > } > > but just a little less beautifully. > > Now the commit you referenced has this older construct still in place. But I > didn't look at the current source code that you are compiling to see what it > has. > > Ken > > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > { } [pool drain]; >> On Jul 16, 2024, at 7:17 AM, Sergey Fedorov <vital....@gmail.com> wrote: >> >> On Tue, Jul 16, 2024 at 6:19 PM Saagar Jha <saa...@saagarjha.com> wrote: >> I’m guessing that since the block runs elsewhere there isn’t an >> autoreleasepool for it anymore. You can probably fix this by wrapping the >> call to JavaMain in @autoreleasepool {}? >> Saagar Jha >> >> This syntax is not supported by GCC, we need to use a standard ObjC somehow. >> >>> >>> On Jul 10, 2024, at 02:47, Riccardo Mottola via macports-dev >>> <macports-dev@lists.macports.org> wrote: >>> >>> Hi, >>> >>> Sergio Had wrote: >>>> I have finally built the thing and it works, from looks of things, but I >>>> get a message on startup: >>>> 36-25% >>>> /opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_java_openjdk8/openjdk8/work/jdk8u-jdk8u372-ga/build/openjdk8/images/j2sdk-image/bin/java >>>> -version >>>> 2024-07-09 18:34:10.587 java[13785:1903] *** __NSAutoreleaseNoPool(): >>>> Object 0x5d12e50 of class NSCFDictionary autoreleased with no pool in >>>> place - just leaking >>>> 2024-07-09 18:34:10.590 java[13785:1903] *** __NSAutoreleaseNoPool(): >>>> Object 0x5d13310 of class NSCFData autoreleased with no pool in place - >>>> just leaking >>>> openjdk version "1.8.0_372" >>>> OpenJDK Runtime Environment (build 1.8.0_372-root_2024_07_09_15_56-b00) >>>> OpenJDK Zero VM (build 25.372-b00, interpreted mode) >>>> >>>> This seems to be related to the code, which upstream has switched to block >>>> syntax (it does not build with GCC), so I had to use its earlier version. >>>> From commit message it seems upstream also had this startup issue: >>>> https://github.com/openjdk/jdk8u/commit/c29d997ca180ba5d812df7745c668cfc906be20b >>> >>> the message tells you that you are using NS* objects without an Autorelease >>> Pool. It will cause issues, but "should work", so your app should run. >>> I notice what they appear to be CoreFoundation bridge object. You should >>> try to track where they come from, maybe put a breakpoint and stacktrace. >>> >>> The snipped seen in the commit looks trivial, no nsblocks needed and has an >>> fresh ARP allocated, so I think the issue is elsewhere. >>> >>> Riccardo >> >
