On Tue, Jul 16, 2024 at 10:47 PM Ken Cunningham < ken.cunningham.web...@gmail.com> wrote:
> 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. > Thank you for the reference, I will try that. > > > > 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 > >> > > > >
