JDK-5076437 : [cinnabar14] mozilla crashes when opening a java applet - intermittent
  • Type: Bug
  • Component: deploy
  • Sub-Component: plugin
  • Affected Version: cinnabar_14,5.0
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: solaris_10
  • CPU: x86
  • Submitted: 2004-07-21
  • Updated: 2004-11-18
  • Resolved: 2004-11-18
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6
5.0u1 b05Fixed 6Resolved
Related Reports
Duplicate :  
JDK-5076485 - [Cinnabar14+] mozilla crash while launch an applet on X86 - intermittent
Description
Log in as new user
Start Mozilla
Open a java applet (eg. test_files/java_applet/clock/index.html)

Bug Mozilla will crash

Note: Mozilla will only crash the first time you attempt to open a java applet after you log in as a new user

Java plugin version:
Java(TM) Plugin-in 1.5.0-beta3-b58

Reporter: can you reproduce this bug on older version? I can't reproduce it on cinnabar14 s10 build61

###@###.### 2004-07-21
================================================================================
Further testing has shown that the bug can be recreated by
Log in as new user
Set up desktop proxy settings
Start Mozilla
Open java aplet

Mozilla will crash

pstack of core shown below

pstack mozilla-bin.1090416070
core 'mozilla-bin.1090416070' of 10314: /usr/sfw/bin/../lib/mozilla/mozilla-bin
 pstack mozilla-bin.1090416070
core 'mozilla-bin.1090416070' of 10314: /usr/sfw/bin/../lib/mozilla/mozilla-bin
-UILocale en-US -contentLocale
-----------------  lwp# 1 / thread# 1  --------------------
 d2722128 realfree (8894cd8) + 97
 d2722736 cleanfree (0) + 44
 d2721bf5 _malloc_unlocked (20, 8676a9c, 8676a58, 1c, 8676a58, d1ff7140) + ad
 d2721b1a malloc   (1c, 80e0988, 1) + 39
 d1ff7140 standard_malloc (0, 88a1578, 80a9d58, b804c3, 80e01b0, 0) + c
 00000001 ???????? (d1f87cc0, 0, 0, d1f86d2e, d20d642f, d1f86d93)
 00000000 ???????? (0, 80e0dc8, 47, 80d1370, 0, 80e0988)
 e0003000 ???????? ()
-----------------  lwp# 3 / thread# 3  --------------------
 d2781b4c __pollsys (d0c2fd10, 1, 0, 0) + c
 d27297b8 poll	   (d0c2fd10, 1, ffffffff) + 68
 d25f045d _pr_poll_with_poll (816d9ec, 1, ffffffff, d0c2ff70, d082570a, 816d9ec) + 2d5
 d25f05d1 PR_Poll  (816d9ec, 1, ffffffff) + 11
 d082570a __1cYnsSocketTransportServiceEPoll6M_i_ (816d698) + 58
 d0825ddd __1cYnsSocketTransportServiceDRun6M_I_ (816d698) + 18f
 d0e90182 __1cInsThreadEMain6Fpv_v_ (816cc40) + 32
 d25f1673 _pt_root (816dca0) + 9e
 d2780af0 _thr_setup (d26b8400) + 50
 d2780cb0 _lwp_start (d26b8400, 0, 0, d0c2fff8, d2780cb0, d26b8400)
-----------------  lwp# 4 / thread# 4  --------------------
 d2780d20 __lwp_park (8283214, 8275038, ceb5fef0) + 10
 d277b543 cond_wait_queue (8283214, 8275038, ceb5fef0, 0) + 3b
 d277b8e0 cond_wait_common (8283214, 8275038, ceb5fef0) + 1df
 d277bb21 _cond_timedwait (8283214, 8275038, ceb5ff50) + 51
 d277bb8c cond_timedwait (8283214, 8275038, ceb5ff50) + 24
 d277bbce pthread_cond_timedwait (8283214, 8275038, ceb5ff50) + 1e
 d25ec578 pt_TimedWait (8283214, 8275038, 5a816a) + b8
 d25ec747 PR_WaitCondVar (8283210, 5a816a) + 64
 d0802f47 __1cOnsIOThreadPoolKThreadFunc6Fpv_v_ (8275000) + 75
 d25f1673 _pt_root (8283430) + 9e
 d2780af0 _thr_setup (d26b8800) + 50
 d2780cb0 _lwp_start (d26b8800, 0, 0, ceb5fff8, d2780cb0, d26b8800)
-----------------  lwp# 5 / thread# 5  --------------------
 d2780d20 __lwp_park (81cf8c4, 81e0a08, ce9efee8) + 10
 d277b543 cond_wait_queue (81cf8c4, 81e0a08, ce9efee8, 0) + 3b
 d277b8e0 cond_wait_common (81cf8c4, 81e0a08, ce9efee8) + 1df
 d277bb21 _cond_timedwait (81cf8c4, 81e0a08, ce9eff48) + 51
 d277bb8c cond_timedwait (81cf8c4, 81e0a08, ce9eff48) + 24
 d277bbce pthread_cond_timedwait (81cf8c4, 81e0a08, ce9eff48) + 1e
 d25ec578 pt_TimedWait (81cf8c4, 81e0a08, 5493) + b8
 d25ec747 PR_WaitCondVar (81cf8c0, 5493) + 64
 d0e9309e __1cLTimerThreadDRun6M_I_ (820b7d8) + 16e
 d0e90182 __1cInsThreadEMain6Fpv_v_ (820af28) + 32
 d25f1673 _pt_root (81650b0) + 9e
 d2780af0 _thr_setup (d26b8c00) + 50
 d2780cb0 _lwp_start (d26b8c00, 0, 0, ce9efff8, d2780cb0, d26b8c00)
-----------------  lwp# 6 / thread# 6  --------------------
 d2780d20 __lwp_park (8283214, 8275038, ce64fef0) + 10
 d277b543 cond_wait_queue (8283214, 8275038, ce64fef0, 0) + 3b
 d277b8e0 cond_wait_common (8283214, 8275038, ce64fef0) + 1df
 d277bb21 _cond_timedwait (8283214, 8275038, ce64ff50) + 51
 d277bb8c cond_timedwait (8283214, 8275038, ce64ff50) + 24
 d277bbce pthread_cond_timedwait (8283214, 8275038, ce64ff50) + 1e
 d25ec578 pt_TimedWait (8283214, 8275038, 5b8d80) + b8
 d25ec747 PR_WaitCondVar (8283210, 5b8d80) + 64
 d0802f47 __1cOnsIOThreadPoolKThreadFunc6Fpv_v_ (8275000) + 75
 d25f1673 _pt_root (8767c48) + 9e
 d2780af0 _thr_setup (d26b9000) + 50
 d2780cb0 _lwp_start (d26b9000, 0, 0, ce64fff8, d2780cb0, d26b9000)
-----------------  lwp# 7 / thread# 7  --------------------
 d2780d20 __lwp_park (8283214, 8275038, ce62fef0) + 10
 d277b543 cond_wait_queue (8283214, 8275038, ce62fef0, 0) + 3b
 d277b8e0 cond_wait_common (8283214, 8275038, ce62fef0) + 1df
 d277bb21 _cond_timedwait (8283214, 8275038, ce62ff50) + 51
 d277bb8c cond_timedwait (8283214, 8275038, ce62ff50) + 24
 d277bbce pthread_cond_timedwait (8283214, 8275038, ce62ff50) + 1e
 d25ec578 pt_TimedWait (8283

David,
Can you get the same stack trace every time you crash? For me, I got several different core files.
###@###.### 2004-07-22
Comments
EVALUATION After some investigation, I find it's very strange. Even new a pointer will crash Mozilla. Seems it is a problem on system. ###@###.### 2004-07-22 On Cinnabar15 on x86, jdk1.5.0-beta3-b58, mozilla1.7(2004/07/26), solaris10-63, the bug can not reproduced. ###@###.### 2004-07-30 On cinnabar17b on x86, jdk1.5.0-beta3-b58, mozillaq1.7, solaris10_66 the bug can be reproduced - reopening this problem is intermittent it may occur the first time you open an applet, it may take several attempts to make it occur (e.g. as frequently as 1 in 5 times) ###@###.### 2004-09-03 Sent a email to plugin team for some help with this bug. ###@###.### 2004-09-21 On Cinnabar19 for X86 and Sparc, the crash seems more easily. Nearly everytime I load suntea.central.sun.com, mozilla will crash! Attach the pstack file. ###@###.### 2004-09-23 Ok, I've installed Cinnabar 17b on x86 machine.. Followed the steps described and launched suntea 10 out of 10 time.. Also, can't access baseman.prc.sun.com not up and running right now.. Is there a machine we can log into to reproduce this issue. How does one create a new user to test this? Do I need to remove/clear something? Or can I just try and launch mozilla -debug and goto suntea website applet? presume I know nothing about creating accounts or profiles or whatever with mozilla. Need better steps and a system to reproduce this on. If you can get this to crash on a sparc that would be best. Also, have you tried running with ###@###.### 2004-09-29 I can't recreate the problem on sparc. I can recreate the problem on cinnabar_19 x86 To create a new user mkdir /export/home/new-user useradd -d /export/home/new-user -s /bin/bash new-user chown /export/home/new-user passwd new-user enter the password to the user Set up a proxy and then open a java applet file, it doesn't have to be sun-tea. Mozilla will crash about once in every 7 attemps to open the file. I tried running with -XX:+ShowMessageBoxonError, the crash still occurred, was this supposed to produce some sort of error message because no error messages where displayed ###@###.### 2004-09-30 see comments.. ###@###.### 2004-09-30 keep investigating ###@###.### 10/9/04 10:13 GMT this bug is not difficult to reproduce, I can get mozilla to crash one in five times using the attached java applet, resetting to P1 - this bug has been marked as a cinnabar stopper if you need a system to test this on, send me a mail ###@###.### 10/12/04 09:59 GMT Hi robert, please copy libjavaplugin_nscp.so from /net/mlei.prc/jws/tiger/output/sparc/lib/sparc/libjavaplugin_nscp.so to your jre environment (backup your original file please), then try to load plugin to see if it still happen. Or you can remove libjavaplugin_oji.so from mozilla plugins directory, then # ln -s /net/mlei.prc/jws/tiger/output/sparc/plugin/sparc/ns7/libjavaplugin_oji.so <your mozilla plugins directory> , then try. I disabled proxy setting in javaplugin in above files to use direct connection, so please do not load applet through proxy. BTW, what's memory amount of your machine ? Currently I suspect there is some issue in JavaScript runtime. I will keep investigating. ###@###.### 10/12/04 11:03 GMT Hi Mike, this is an x86 bug, you provided links to sparc plugins - ?? I created a link to libjavaplugin_oji.so at /net/mlei.prc/jws/tiger/output/x86/plugin/i386/ns7 now mozilla gives error message no java pluing available. ###@###.### 10/12/04 12:03 GMT This bug also happens on sparc. I just built a x86 version, would you please try again ? ###@###.### 10/13/04 03:46 GMT root cause found. fixing. ###@###.### 10/19/04 01:47 GMT verified fixed in cinnabar_23 ###@###.### 2004-11-18 18:12:23 GMT
13-10-0004