RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

[Alan Bateman]

On 05/09/2013 22:30, Brent Christian wrote:
> :
>
> I plan to label this as "noreg-hard" - signing an .app bundle requires 
> Keychain setup for any machine running the test.
>
> Webrev is here:
> http://cr.openjdk.java.net/~bchristi/7199674/webrev.00/
>
> (One note - the change to
>   make/common/Defs-macosx.gmk
> is not, strictly speaking, part of this fix, but was necessary for the 
> "old build" to finish on my OS X 10.8.4 system.  I've left it in.)
I don't know Cocoa memory management but from a quick look at the 
NSAutoreleasePool docs then what you seems to be right. Folks on 
macosx-port-dev would be better to comment on that.

I see that createUTF8CString doesn't handle malloc failing and it's not 
clear how CFStringGetCString behaves when called with NULL. In any case, 
this is all early startup and if we have malloc failing this early then 
we aren't going to get very far.

One comment on the error case (fallback to "?") as this is now 
duplicated. It might be better to have this fallback in one place 
(GetJavaProperties) as I'm pretty sure we'll need to re-examine it at 
some point (we periodically hear about environments where 
user.name/user.home end up as "?", it's been mis-configured systems in 
all cases that I've looked at but arguably we should fail rather than 
use "?").

The update to the old build is only interesting if this is back-ported 
to jdk7u. Hopefully Erik or someone in the build team will be allowed to 
set their phasers to kill soon.

-Alan.