Hi all,
I had the system people here at the Mathworks apply all outstanding patches
to the Solaris OS running on my SPARC workstation. Now JDEbug works
perfectly, albeit stepping is slow because the vm is running in interpreted
mode (no need for "classic" switch). Here is my configuration:
Sun Microsystems Ultra 5-10 SPARC workstation
SunOS 5.6 Generic_105181-20
JDK 1.3.0 (Reference Implementation)
Emacs 20.3.1
JDE 2.2.6.2
So the bottom line is this. If you're having trouble running JDEbug on Solaris:
1) Make sure you are using the REFERENCE version of JDK 1.2 or 1.3.
2) Make sure that you are running SunOS 5.6 with all the latest patches
installed.
- Paul
At 12:58 PM 1/5/01 +0100, Richard den Adel wrote:
>Hi Tim,
>
>I downloaded the latest jdk1.2.2 reference implemenation. I have
>attached the results at the bottom of this email.
>
>hope this helps,
>
>Richard
>
>Tim Bell wrote:
>
>> Hello everyone
>>
>> I wanted to let you know that we have received your email
>> regarding errors when running JDE (based on JPDA) on Solaris
>> systems.
>>
>> I'm at home this week during the annual holiday shutdown/winter
>> break, and my computer is in an unheated garage. I'll try to
>> investigate this a bit this week, but realistically speaking,
>> you probably won't hear from me until next week (first week
>> of January, 2001).
>>
>> Until then, please check the following (you may already
>> know this, so excuse me if this is going over old ground):
>>
>> 1) Make sure you are using a "Reference Implementation" of the
>> JDK and not the "Solaris Production" VM releases. The reference
>> releases are available at these URLs:
>> http://java.sun.com/products/jdk/1.2/download-solaris.html
>> http://java.sun.com/j2se/1.3/download-solaris.html
>>
>> 2) Verify that you are running all the recommended patches
>> for the release of Solaris you have. Check the lists at
>> these URLs:
>> http://java.sun.com/j2se/1.3/install-solaris-patches.html
>> http://java.sun.com/products/jdk/1.2/install-solaris-patches.html
>>
>> Paul wrote:
>>
>>> I have not yet succeeded in getting JDK 1.3.0 running on Solaris.
>>
>>
>> I use JDK 1.3.0 on Solaris all day long. I'd be very interested
>> in more details on the problems you are experiencing.
>>
>> Best regards. I'll send more information next week.
>>
>> Tim
>>
>> Tim Bell [EMAIL PROTECTED]
>> Sun Microsystems, Inc. Java Software Core Java Engineering
>>
>>
>>> Hi Richard,
>>>
>>> I tested JDEbug on various versions of the JDK on Solaris. Here are the
>>> results:
>>>
>>>
>>> VM Result
>>>
----------------------------------------------------------------------------
>>> ------------------
>>> JDK 1.2.1_03 Failed (VMDisconnected exception)
>>> JDK 1.2.1_04 Succeeded.
>>> JDK 1.2.2_00 Failed (dt_transport: connection refused)
>>> JDK 1.2.2_05 Failed (dt_transport: connection refused)
>>>
>>> I have not yet succeeded in getting JDK 1.3.0 running on Solaris.
>>>
>>> - Paul
>>
>>
>>
>> Tim Bell [EMAIL PROTECTED]
>> Sun Microsystems, Inc. Java Software Core Java Engineering
>>
>richard@gravity:~/tmp$ /tmp/richard/jdk1.2.2/bin/java -native -classic
>-Xdebug -Xnoagent
>-Xrunjdwp:transport=dt_socket,address=localhost:4000,suspend=y
>-Djava.security.policy=/home/richard/src/acriter/policy.all -Xms40m
>-Xmx80m com.acriter.bms.Main
>Error [146] in connect() call!
>err:: Connection refused
>Socket transport failed to init.
>Transport dt_socket failed to initialize, rc = -1.
>FATAL ERROR in native method: No transports initialized
>SIGABRT 6* abort (generated by abort(3) routine)
> si_signo [6]: SIGABRT 6* abort (generated by abort(3) routine)
> si_errno [0]: Error 0
> si_code [-1]: SI_LWP [pid: 28464, uid: 118]
> stackpointer=ffbeb0b4
>
>Full thread dump Classic VM (JDK-1.2.2_007, native threads):
> "Finalizer" (TID:0xf9800320, sys_thread_t:0x73e48, state:CW, native
>ID:0x6) prio=8
> at java.lang.Object.wait(Native Method)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:112)
> at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:127)
> at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:174)
> "Reference Handler" (TID:0xf98003b0, sys_thread_t:0x6f9c0, state:CW,
>native ID:0x5) prio=10
> at java.lang.Object.wait(Native Method)
> at java.lang.Object.wait(Object.java:424)
> at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:114)
> "Signal dispatcher" (TID:0xf98003e0, sys_thread_t:0x6a9a8, state:CW,
>native ID:0x4) prio=5
> "main" (TID:0xf98001e0, sys_thread_t:0x319f0, state:R, native ID:0x1)
>prio=5
>Monitor Cache Dump:
> java.lang.ref.Reference$Lock@F98003C0/FA0027F0: <unowned>
> Waiting to be notified:
> "Reference Handler" (0x6f9c0)
> java.lang.ref.ReferenceQueue$Lock@F9800338/FA002CF8: <unowned>
> Waiting to be notified:
> "Finalizer" (0x73e48)
>Registered Monitor Dump:
> JDWP Transport Send Monitor: <unowned>
> JDWP Transport Listener Monitor: <unowned>
> JDWP Initialization Monitor: <unowned>
> JDWP Invocation Lock: <unowned>
> JDWP Step Handler Lock: <unowned>
> JDWP Thread Lock: <unowned>
> JDWP Reference Table Monitor: <unowned>
> JDWP Alloc Lock: <unowned>
> utf8 hash table: <unowned>
> JNI pinning lock: <unowned>
> JNI global reference lock: <unowned>
> BinClass lock: <unowned>
> Class linking lock: <unowned>
> System class loader lock: <unowned>
> Code rewrite lock: <unowned>
> Heap lock: <unowned>
> Monitor cache lock: owner "main" (0x319f0) 1 entry
> Thread queue lock: owner "main" (0x319f0) 1 entry
> Monitor registry: owner "main" (0x319f0) 1 entry
>
>Abort
>richard@gravity:~/tmp$
>
