Fantastic - thanks Anthony et al. for following up. I'm not quite sure of the procedure to nominate this patch for inclusion in the jdk7u sources as well - would it be helpful for me to bring this up on the jdk7u-dev list?
Cheers, James On Thu, May 30, 2013 at 10:14 AM, Anthony Petrov <[email protected]>wrote: > Hi James, > > Thank you very much for the contribution! Your fix is now pushed to the > repository: > > http://hg.openjdk.java.net/**jdk8/awt/jdk/rev/768fcc36182a<http://hg.openjdk.java.net/jdk8/awt/jdk/rev/768fcc36182a> > > -- > best regards, > Anthony > > > On 05/29/13 01:30, James Tomson wrote: > >> Running the Leaks instrument while triggering multiple openURIs (and >> openFile, and printFile events) and neither the descriptors or the >> queued blocks are flagged as leaked. I've only had a chance to run the >> profile against a patched jdk7u, not a patched jdk8. >> >> Cheers, >> James >> >> >> On Mon, May 27, 2013 at 1:23 PM, Mike Swingler <[email protected] >> <mailto:[email protected]>> wrote: >> >> This looks reasonable to me. Did you test the fix using the "leaks" >> to determine that the descriptors or the block itself were not >> over-retained? >> >> Regards, >> Mike Swingler >> Apple Inc. >> >> On May 27, 2013, at 6:53 AM, Anthony Petrov >> <[email protected] >> <mailto:anthony.petrov@oracle.**com<[email protected]>>> >> wrote: >> >> > Thanks for testing, James. I'm fine with the fix then. >> > >> > Note that we need at least one more review from a reviewer on >> this mailing list before we can push your fix to the repository. >> > >> > Anyone? >> > >> > -- >> > best regards, >> > Anthony >> > >> > On 05/24/13 22:39, James Tomson wrote: >> >> Hi Anthony, >> >> >> >> Thanks for taking a look. To answer your questions, the >> >> application:openFiles and application:printFiles methods should >> not need >> >> similar special treatment - the passed instances should be getting >> >> implicitly retained and released by the block from my >> understanding, and >> >> can be queued for later processing without a problem. Testing >> locally >> >> with those handlers, the OpenFilesEvent and PrintFilesEvent >> events on >> >> the java-side are delivered without issue when the app is >> launched from >> >> an open file or print file event from the Finder. >> >> >> >> The issue with the passed NSAppleEventDescriptors is that while >> the >> >> objects are properly retained and released by the block, the >> Apple Event >> >> Handling system seems to be marking the instance's internal state >> as >> >> otherwise invalid/expired even though the instance itself is still >> >> retained. I'm unable to find any specific documentation or >> discussion >> >> about the lifecycle of these event descriptor objects though. >> >> >> >> -James >> >> >> >> >> >> On Fri, May 24, 2013 at 12:13 PM, Anthony Petrov >> >> <[email protected] >> <mailto:anthony.petrov@oracle.**com<[email protected]> >> > >> <mailto:anthony.petrov@oracle.**com <[email protected]> >> >> <mailto:anthony.petrov@oracle.**com <[email protected]>>>> >> wrote: >> >> >> >> Hi James, >> >> >> >> I like your patch. >> >> >> >> Do you know if other handlers are affected by a similar issue? >> In >> >> particular, the application:openFiles and >> application:printFiles >> >> also take references to NSObjects as their arguments. Could you >> >> please test if these handlers are affected or not? >> >> >> >> -- >> >> best regards, >> >> Anthony >> >> >> >> >> >> On 05/23/2013 10:56 PM, James Tomson wrote: >> >> >> >> Hi - this issue was originally discussed on the jdk7u-dev >> list here: >> >> >> http://mail.openjdk.java.net/_**_pipermail/jdk7u-dev/2013-May/** >> __006446.html<http://mail.openjdk.java.net/__pipermail/jdk7u-dev/2013-May/__006446.html> >> >> >> <http://mail.openjdk.java.net/**pipermail/jdk7u-dev/2013-May/** >> 006446.html<http://mail.openjdk.java.net/pipermail/jdk7u-dev/2013-May/006446.html> >> > >> >> >> >> Additionally a report should be available soon in the bug >> >> database as >> >> (JDK-8015302) >> >> http://bugs.sun.com/__**bugdatabase/view_bug.do?bug___** >> id=8015302<http://bugs.sun.com/__bugdatabase/view_bug.do?bug___id=8015302> >> >> >> <http://bugs.sun.com/**bugdatabase/view_bug.do?bug_**id=8015302<http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8015302> >> > >> >> >> >> To summarize, a bundled mac application which registers >> custom url >> >> schemes via the CFBundleURLSchemes entry in its >> Info.plist, and >> >> listens >> >> for uri events using >> >> com.apple.eawt.Application.__**setOpenURIHandler, will >> >> not receive the URI used to launch the application. >> >> >> >> Once the application is running however, subsequent openURI >> >> events will >> >> be delivered without issue. The problem only manifests >> with the >> >> URI is >> >> used to launch the App initially. >> >> >> >> When the app is opened via URI, the following appears in >> the >> >> system log: >> >> >> >> ---------- >> >> JavaAppLauncher[74278]: -[NSAppleEventDescriptor >> >> paramDescriptorForKeyword:] called on invalid >> NSAppleEventDescriptor >> >> ---------- >> >> >> >> It appears that since the QueueingApplicationDelegate is >> only >> >> keeping >> >> references to those descriptor objects instead of making >> deep >> >> copies of >> >> them, >> >> the event descriptor for the initial URI that launches >> the app is >> >> invalidated by the time the app actually gets around to >> >> processing it. >> >> >> >> The following patch (same for both jdk8 and jdk7u >> sources) seems to >> >> resolve the issue: >> >> >> >> ---- >> >> diff --git >> >> >> a/src/macosx/native/sun/__**osxapp/__**QueuingApplicationDelegate.m >> >> >> b/src/macosx/native/sun/__**osxapp/__**QueuingApplicationDelegate.m >> >> --- >> a/src/macosx/native/sun/__**osxapp/__**QueuingApplicationDelegate.m >> >> +++ >> b/src/macosx/native/sun/__**osxapp/__**QueuingApplicationDelegate.m >> >> @@ -110,8 +110,14 @@ >> >> >> >> - (void)_handleOpenURLEvent:(__**NSAppleEventDescriptor >> >> *)openURLEvent >> >> withReplyEvent:(__**NSAppleEventDescriptor *)replyEvent >> >> { >> >> + // Make an explicit copy of the passed events as >> they may be >> >> invalidated by the time they're processed >> >> + NSAppleEventDescriptor *openURLEventCopy = >> [openURLEvent copy]; >> >> + NSAppleEventDescriptor *replyEventCopy = [replyEvent >> copy]; >> >> + >> >> [self.queue addObject:[^(){ >> >> - [self.realDelegate >> _handleOpenURLEvent:__**openURLEvent >> >> withReplyEvent:replyEvent]; >> >> + [self.realDelegate >> _handleOpenURLEvent:__**openURLEventCopy >> >> withReplyEvent:replyEventCopy]**__; >> >> + [openURLEventCopy release]; >> >> + [replyEventCopy release]; >> >> } copy]]; >> >> } >> >> ----- >> >> >> >> Please let me know if there is additional information >> that I can >> >> provide >> >> - thanks! >> >> >> >> -James >> >> >> >> >> >> >>
