If user goes to a password protected site with HotJava, after filling in username and password and clicking ok, JVM will crash with seg. fault. This doesn't always happen, but occurs frequently. Stack trace is below. This occurs with jvm111_16 (native_threads) and HotJava1.0_18.

(jelvehg 4/30/97)
 Attempts to "consistently" reproduce this bug have failed. The core dump occurs almost once in ten passes through the user authentication. In some cases, the core dumps persist on happening consecutively right after the first core dump. The issue could also be based on using <ENTER> or <TAB> keys instead of just using mouse to move between fields. Please note that the bug has also occured while using jvm111_17 with HotJava1.0_18. The bug is not necessarily site-pecific related, and any client/server installtion procedure (i.e. Genie, Solaris Web Start Session) can be used as a means of reproducing. OS version of the testing scenarios is 2.6.

(jelvehg 5/2/97)
In order to reproduce the bug via client/server mode of Genie the command "boot net - browser" should be used on the ok prompt (the user should then proceed as instructed by the program). It is recommended to use a headless server. If a headless server is not available, simply disconnect the keyboard (this causes the output device to point to ttya) and attach a tip cable to the server.

(jelvehg 5/13/97)
The bug has been happening again a few times. Additional core files and HotJava logs are being attached. This happens based on HotJava version 19, JVM version 18, and Solaris 2.6.

(jelvehg 5/13/97)
Attaching another set of traced core file (auth_core_trace_0513.log) and HotJava log file (auth_core_hotjava_0513.log).


(jelvehg 5/22/97)
Crashes occure consistently based on the following steps:
1- Bring up a password protected web site via HotJava.
2- kill Hotjava via the "kill -9 " command.
3- Bring up a password protected web site via HotJava again, and click on the <ok> button after providing the username and password.

Please refer to the core-after-kill-trace (the trace of the core file), and the core-after-kill-hotjava.log (the hotjava log file).

(jelvehg 6/3/97)
The client machine where this bug has been happening "very frequently" has the following characteristics:
SPARCstation 10
Sun4m Kernel architecture
48 MB of physical memory
1 sun1.05 GB disk
5.6 Beta-update
CDE 1.2-22
The bug has occured on the following JVM versions: 17, 18, 19, 20, 21, 22
The bug has occured on the following HotJava versions: 18, 19, and 20.


(jelvehg 6/4/97)
Oscar Arreola has accomodated me with the attached hotjava.log.authentication.60397 hotjava log file which is another illustration of the bug. He is using HotJava version 20, JVM version 22, and the latest version of Genie.


(jelvehg, 6/25/97)
Addition of yet another attachment ht.log_23.91997 to attest to the reproducibility of this bug.


(./dbx) where
current thread: t@32
=>[1] __lwp_kill(0x0, 0x6, 0xee550fc8, 0xb, 0xee551e60, 0xee551e40), at 0xef4b9104
  [2] __libthread_segvhdlr(0xb, 0xee551188, 0xee550fc8, 0xee550f08, 0xef554aec, 0xee551e40), at 0xef542a64
  ---- called from signal handler with signal 11 (SIGSEGV) ------
  [3] _Ximp_Local_Filter(), at 0xee482518
  [4] XFilterEvent(0xee5513f4, 0x400029e, 0x1, 0x15f610, 0x52e790, 0x15f60c), at 0xef652f08
  [5] _XtDefaultDispatcher(0xee5513f4, 0x1, 0x0, 0x15f60c, 0x0, 0x538450), at 0xee6ddb28
  [6] XtDispatchEvent(0xee5513f4, 0x1, 0xee6dd7a4, 0xee720104, 0x0, 0x2), at 0xee6dddec
  [7] RemoveAllPMgr(0x52e790, 0xee87a4d8, 0x1, 0x1, 0x534450, 0xee70f8d3), at 0xee87a6ac
  [8] XtCallCallbackList(0x52e790, 0x531f50, 0x0, 0x0, 0x0, 0x1), at 0xee6cf94c
  [9] XtPhase2Destroy(0x52e790, 0xffffffff, 0x0, 0xee720104, 0xee6d0020, 0x0), at 0xee6d81b0
  [10] _XtDoPhase2Destroy(0x15cbb0, 0x0, 0x0, 0x0, 0x0, 0x15cbb0), at 0xee6d83c8
  [11] XtDestroyWidget(0x52e790, 0xee720104, 0x15cbb0, 0x22974, 0xeea41000, 0xeea41000), at 0xee6d85d8
  [12] sun_awt_motif_MDialogPeer_pDispose(0xec5d7600, 0xee968c00, 0x53b038, 0x0, 0xd20, 0x530540), at 0xee929c50
  [13] JITUnsynchronizedNativeStub(0xec5d7600, 0xec5d7600, 0x0, 0x22b24, 0xec5b2d80, 0xec5b26c0), at 0xeea2f4ac
  [14] 0x53b804(0xec5d7600, 0xe, 0x5308e8, 0x530740, 0xec5d7620, 0xec5b26c0), at 0x53b803
  [15] 0x260308(0xec5d8208, 0x0, 0xec5d7600, 0x0, 0x1a10, 0x127498), at 0x260307
  [16] 0x261210(0xec5d8208, 0x6, 0x6, 0x22ab8, 0xec5d7620, 0xec5b26c0), at 0x26120f
  [17] 0x54e074(0xec5d8208, 0xee551cbc, 0xef7ac318, 0xee551824, 0xee551bcc, 0xee551bd4), at 0x54e073
  [18] 0x545afc(0xec5d8208, 0xec5d5ce8, 0x529ea8, 0x524a60, 0xec5d85a0, 0xec5990a0), at 0x545afb
  [19] 0xe7b4c(0xec5d5ce0, 0x6c060, 0x543a94, 0x25750, 0xee551bcc, 0xee551bd4), at 0xe7b4b
  [20] JITInvokeCompiledMethod(0xec5d5ce0, 0x6c060, 0x1, 0xee551cbc, 0xef74db14, 0xee551bd4), at 0xeea2f3e0
  [21] finish_invokevirtual(0xee551bec, 0xee551cbc, 0x543abc, 0x0, 0xee551bd4, 0x543a94), at 0xef787ee0
  [22] do_execute_java_method_vararg(0xee551cbc, 0xef7a5edd, 0x0, 0x0, 0x0, 0x543a80), at 0xef75dac4
  [23] execute_java_dynamic_method(0xee551cbc, 0xec5d5ce0, 0xef7a5ed8, 0xef7a5edc, 0xef7a8800, 0xef53e488), at 0xef75d168
  [24] ThreadRT0(0xec5d5ce0, 0xef7a5edc, 0x21000, 0xef554aec, 0x4, 0x53e0a8), at 0xef777e88
  [25] _start(0x0, 0xef003d98, 0x0, 0xef55d704, 0x1, 0x41401080), at 0xef7843c4