Greg Guerin made some suggestions for experiments with NetBeans Terminal and
Finder launching. I have done some of them. Here are the results so far:
Greg Guerin wrote (9/27/08 10:36 AM):
> ...
>
> ... 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.
>
My Terminal command's environment is initialized from the file
.bash_profile
I did several experiments modifying that file and noting the results. I was
able to make the Terminal invocation fail. Here's what I did. Maybe someone
can make better sense of it than me:
The initial .bash_profile was:
export PS1='[\h:\W] \u\$ '
export JAVA_HOME=/Library/Java/Home
export ANT_HOME=/usr/share/ant
export CATALINA_HOME=/Library/Tomcat
export GROOVY_HOME=/Downloads/++Java-XML-XSL\ Related/groovy-1.0-RC-02
##
# USR-LOCAL-BIN-INSERT
##
echo $PATH | grep -q -s "/usr/local/bin"
if [ $? -eq 1 ] ; then
PATH=$PATH:/usr/local/bin
fi
export PATH
alias bb=bbedit
The above works (Terminal successfully launches NetBeans).
If I comment out the exports
JAVA_HOME
ANT_HOME
CATALINA_HOME
GROOVY_HOME
in every other possible combination (15 total) the Terminal launch fails
with the following error line in Terminal:
[FlyingMonkeys:~] gnunes$ open "/Applications/NetBeans/NetBeans 6.1.app"
LSOpenFromURLSpec() failed with error -10810 for the file
/Applications/NetBeans/NetBeans 6.1.app.
and an associated 64-bit crash log (like those presented in previous posts).
Only the combination where all variables are defined works. It should also
be noted that the only relevant differences (I think) between the working
Terminal environment and Finder environment are the above definitions (from
comparing "set" + other command outputs from both environments ... but let
me know if you want any other kind of comparision).
Go figure.
>
> 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" '&'
>
I tried the above and it works, i.e., Finder launch succeeds (actually both
Finder and Terminal launches succeed after this change because both,
ultimately use the modified shell script).
Definitely seems like a 32 vs. 64-bit mode problem of some sort. But what
kind and why (again, I can find no explicit setting of 64-bit mode).
Regards,
gary
_______________________________________________
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
