I will add elements of this discussion to both the NetBeans and
Apple bug
reports. I think you may have something in surmising that running
in 64-bit
mode is the problem. The question then is, what's causing the app
to run in
64-bit mode on an apparently small subset of machines (or possibly
why is
that a problem on such machines)?
I counted of the args on the command-line, using the values given here:
And reading the NB bug reports cited, I see that it *is* the same
problem.
Since the NB launch works from the Terminal command-line, I'd look to
see what differs between the two environments. Maybe you have
something in your bash profile that prevents the problem from occurring.
First thing, I'd add a 'printenv' to the NB.app shell-script that
logs to a suitable file, and then do a diff of the crashing output
against the working output.
There's more to the environment than env-vars, though, so things like
current working directory, real and effective user ids (and group
ids), etc. The shell has some ability to show those, for others,
there are commands like 'id'.
Also, I might try a counter-strategy.
Instead of trying to make NetBeans.app work when double-clicked in
Finder, try to make the 'open -a ...' command-line fail with the same
SEGV in Terminal. I'm not quite sure how to approach that, but I'd
start with the environmental diffs collected earlier.
If you can get the Terminal one to fail, you should be able to attach
'gdb' to it and figure out the point where it's dying. Or just add
'gdb' to the shell script and do some tracing.
Another idea: force execution of the 32-bit binary.
Taking the evidence that it's crashing in 64-bit code, but also that
it eventually runs NetBeans itself under the 32-bit JVM, I'm
wondering if there's an obscure or hard-to-trigger bug in the 64-bit
native code of the '1.5/Home/bin/java' command itself.
The 'arch' command can be used to specify execution of a particular
architecture in a Universal Binary executable. So in this command-
line from the shell script:
Finally, I'd consider a full-scale launcher replacement, for testing
purposes.
You have (or can get) all the command-line args for the 'java'
command. Translate those into a suitable Info.plist, then put that
Info.plist into a copy of NetBeans.app, along with a copy of the
JavaApplicationStub launcher.
The idea is to use a completely different launcher just to see if it
can get NB off the ground. I realize this is not reconfigurable in
the same way that a netbeans.conf file is. Nor is it as dynamic as a
shell file. This is only a test.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
