United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-7124511 [macosx] Strange NullPointerException (err message: 'CFMessagePort: bootstrap_register(): failed 110
JDK-7124511 : [macosx] Strange NullPointerException (err message: 'CFMessagePort: bootstrap_register(): failed 110

Details
Type:
Bug
Submit Date:
2011-12-23
Status:
Closed
Updated Date:
2012-03-23
Project Name:
JDK
Resolved Date:
2012-03-05
Component:
client-libs
OS:
os_x
Sub-Component:
java.awt
CPU:
generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
7
Fixed Versions:
7u4 (b11)

Related Reports
Relates:
Relates:

Sub Tasks

Description
http://java.net/jira/browse/MACOSX_PORT-774 submitted 2011/12/14 by Taras Ledkov
For JCK tests, there are strange error message in test logs:
<div class=&quot;code panel&quot; style=&quot;border-width: 1px;&quot;><div class=&quot;codeContent panelContent&quot;><pre class=&quot;code-java&quot;>2011-12-10 06:25:16.343 java[43989:707] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x5403, name = 'WakeUpProcessPort'See /usr/include/servers/bootstrap_defs.h <span class=&quot;code-keyword&quot;>for</span> the error codes.2011-12-10 06:25:16.843 java[43989:707] *** CFMessagePort: bootstrap_register(): failed 1100 (0x44c) 'Permission denied', port = 0x6f0b, name = 'com.apple.tsm.portname'See /usr/include/servers/bootstrap_defs.h <span class=&quot;code-keyword&quot;>for</span> the error codes.</pre>

                                    

Comments
EVALUATION

Author: Mike Swingler Date: 14/Dec/11 08:58 PM
This is what happens when a process tries to initialize AppKit while it is not running under a graphical bootstrap session. We had checks for this in the lowest level of the Java command line launcher but they were removed.
 
Author: Anthony Petrov Date: 16/Dec/11 12:00 PM
Are you referring to <a href=&quot;/jira/browse/MACOSX_PORT-765&quot; title=&quot;Unable to run an GUI app remotely.&quot;><del>MACOSX_PORT-765</del></a> with a fix at <span class=&quot;nobr&quot;><a href=&quot;http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c50bdc544e22&quot;>http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/c50bdc544e22<sup><img class=&quot;rendericon&quot; src=&quot;/jira/images/icons/linkext7.gif&quot; height=&quot;7&quot; width=&quot;7&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/></sup></a></span> ?
 
Author: Mike Swingler Date: 16/Dec/11 05:11 PM
Yes. I think the right thing to do is to force headless or X11 when a request is made to load the native Cocoa/AWT, but the process is running in a non-graphical session.
 
Author: Alexander Zuev Date: 16/Dec/11 06:07 PM
I don't think that fallback to either X11 or headless will help the purpose of distributed testing started off the remotely controlled daemons. What is more interesting to me is why these errors appear in the first place. Systems should be configured to never go to sleep mode or autolock and that the owner of the daemon process should be logged in at all times - in this case there should be no problem running GUI applications from that daemon. Some investigation required. Probably we can catch that specific error in native code and just fall gracefully - like showing in output error such as &quot;Attempt to connect to graphical session failed: Permission denied.&quot; and exit from application with negative return value.
 
Author: Mike Swingler Date: 16/Dec/11 06:35 PM
If the automation is kicked off by launchd, you need to make sure that process is run by the console user, and that the session type is &quot;Aqua&quot;. See <span class=&quot;nobr&quot;><a href=&quot;http://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man1/launchctl.1.html&quot;>http://developer.apple.com/library/mac/#documentation/Darwin/Reference/Manpages/man1/launchctl.1.html<sup><img class=&quot;rendericon&quot; src=&quot;/jira/images/icons/linkext7.gif&quot; height=&quot;7&quot; width=&quot;7&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/></sup></a></span> for more information about what to put into the launchd plist to make that happen.
 
Author: Mike Swingler Date: 16/Dec/11 06:36 PM
I also firmly believe you shouldn't set the user up to fail, so if there is action we can take to avoid the inevitable failures in Cocoa when run under a non-graphical environment, we should just do it.
 
Author: Anthony Petrov Date: 19/Dec/11 12:39 PM
I agree with Mike: if the session doesn't support graphics, then we should silently fall back to the headless mode rather than pretend we might try to do something and fail later anyway.
What concerns me though, is that the end user might not realize why the headless mode has been turned on. This may confuse users when they catch Headless exception.
In theory we might actually error out right away because generally it's user's responsibility to specify that they want to run in the headless mode. If the environment doesn't support graphics, and the headless mode hasn't been explicitly requested - an exception thrown upon loading the AWT seems to be quite nice.
So, which path do we choose? Personally, I'm 66% in favor of the 2nd one, and 33% of the first (given we find a way to notify the user that the mode has been enabled implicitly).
What are your opinions?
 
Author: Anthony Petrov Date: 19/Dec/11 07:26 PM
Artem and I have discussed the issue in person, and now I'm convinced that falling back to the headless mode in this situation is actually OK. An app can call the GraphicsEnvironment.isHeadless() method to determine whether there's a display available.
 
Author: Anthony Petrov Date: 21/Dec/11 11:15 AM
The fix is at:
<span class=&quot;nobr&quot;><a href=&quot;http://cr.openjdk.java.net/~anthony/x-5-forceHeadless.0/&quot;>http://cr.openjdk.java.net/~anthony/x-5-forceHeadless.0/<sup><img class=&quot;rendericon&quot; src=&quot;/jira/images/icons/linkext7.gif&quot; height=&quot;7&quot; width=&quot;7&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/></sup></a></span>
Reviewed at:
<span class=&quot;nobr&quot;><a href=&quot;http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-December/001883.html&quot;>http://mail.openjdk.java.net/pipermail/macosx-port-dev/2011-December/001883.html<sup><img class=&quot;rendericon&quot; src=&quot;/jira/images/icons/linkext7.gif&quot; height=&quot;7&quot; width=&quot;7&quot; align=&quot;absmiddle&quot; alt=&quot;&quot; border=&quot;0&quot;/></sup></a></span>
Will be pushed after the migration of the macosx-port repository to the 7uosx-dev.
                                     
2011-12-23
EVALUATION

8-na: the fix is integrated as a part of 7113349.
                                     
2012-03-23



Hardware and Software, Engineered to Work Together