Greg,
Thanks for the advice.
I'll try your suggestions (if I'm able) and report the results.
Some additional info:
- JetBrains (IDEA) says doing a compile/rebuild doesn't do anything special
(e.g., go to 64-bit mode), just calls out to the JVM using standard APIs.
- If I use IDEA to generate an Ant script for a project, the Ant script can
successfully compile/rebuild the project, i.e., it's IDEA's menu-based
invocation to compile/rebuild that fails.
- I agree that, ultimately, my and Jim Rome's and a few others problem is
most likely some kind of environmental difference from the majority of Java
installations since most users' NetBeans and IDEAs work (as reported by the
respective companies). Whatever happened though must have been a side-effect
of something else. No explicit changes to the Java environment have been
done, at least by me (with one exception ... see the next point).
- I think, though I'm not positive, that things started going wrong sometime
after the OS upgrade that brought Java 1.6 onto my machine but, even after
that upgrade, things did not fail immediately. The initial failure (for me)
was between two IDEA compilations an hour or so apart: the earlier
compilation worked, the later (and succeeding compilations) fail.
Regards,
gary
Greg Guerin wrote (9/27/08 10:36 AM):
> Gary Nunes wrote:
>
> I counted of the args on the command-line, using the values given here:
>
> http://lists.apple.com/archives/java-dev/2008/Sep/msg00412.html
>
> By my count, it ends up with more than 25, which reminded me of this
> problem:
>
> http://lists.apple.com/archives/Java-dev/2008/Sep/msg00102.html
>
> http://lists.apple.com/archives/Java-dev/2008/Sep/msg00092.html
>
> 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:
>
> eval ${_NB_PROFILE_CMD} "\"${jdkhome}/bin/java\""
> -Djdk.home="\"${jdkhome}\"" -classpath "\"$cp\"" \
> $jargs org.netbeans.Main "$args" '&'
>
> change it to:
>
> ARCH_CMD="/usr/bin/arch -i386";
> eval ${ARCH_CMD} ${_NB_PROFILE_CMD} "\"${jdkhome}/bin/java\""
> -Djdk.home="\"${jdkhome}\"" -classpath "\"$cp\"" \
> $jargs org.netbeans.Main "$args" '&'
>
>
> 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
>
> This email sent to email@hidden
>
_______________________________________________
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
This email sent to email@hidden
