EVALUATION
I can not run /home/kg/bin/mozilla1.1 even I set my DISPLAY env. I wonder how you get Mozilla 1.1 since Mozilla community does not provide a forte build. Did you build mozilla using forte tools yourself?
###@###.### 2002-09-13
Reporter, please answer my question above.
###@###.### 2002-09-16
###@###.### 2002-09-16
See comments by edp. I run his build out of /home/kg/bin/mozilla1.1. What do you
mean that you "can not run mozilla even I set my DISPLAY env" ? Do you get
an error message? Have you tried accessing that URL using the same java plugin
with a different browser? Have you run the core file that I provided through a
debugger and tried doing some post-mortem investigation?
###@###.### 2002-09-16
Okay, I rlogin to galago and setenv DISPLAY xlu:0.0. I then ran /home/kg/bin/mozilla1.1 &. I got the following message:
Gtk-WARNING **: cannot open display: xlu:0.0.
###@###.### 2002-09-16
That warning means you have not granted remote access to your display. On your
local machine, you need to use the "xhost" command to do this. Try "xhost
galago" and re-running mozilla.
###@###.### 2002-09-16
couple more things.
- make sure you in the .eng domain. if your not then be sure
to set the display variable to xlu.<your_domain_here>:0.0
- make sure your using :0.0 locally. to check this open an xterm, dtterm,
gterm, etc and type "echo $DISPLAY"
###@###.### 2002-09-16
I did all the above and still can not launch Mozilla 1.1 successfully. I would like to downgrade the priority of this bug since we are not supporting Mozilla browser officially.
###@###.### 2002-09-16
This is my analysis based on the core file.
[1] __sigprocmask(0x0, 0xf2000398, 0x0, 0x0, 0x0, 0x0), at 0xff369790
[2] _resetsig(0xff36bf68, 0x0, 0x0, 0xf2001d70, 0xff37e000, 0x0), at 0xff35e9ac
[3] _sigon(0xf2001d70, 0xff385938, 0x6, 0xf200046c, 0xf2001d70, 0x6), at 0xff35e14c
[4] _thrp_kill(0x0, 0x1a, 0x6, 0xff37e000, 0x1a, 0xff2be460), at 0xff36118c
[5] raise(0x6, 0x0, 0x0, 0xffffffff, 0xff2be3cc, 0x4), at 0xff24b738
[6] abort(0xff2ba004, 0xf20005c0, 0x0, 0xfffffff8, 0x4, 0xf20005e1), at 0xff235aac
[7] os::abort(0x1, 0xfe3eb40f, 0xf2000660, 0x0, 0xfe4374a8, 0xfe32c994), at 0xfe32e0b8
[8] os::handle_unexpected_exception(0x35de98, 0xb, 0xfe0e8bd8, 0xf2001398, 0xb, 0x0), at 0xfe32ca04
[9] JVM_handle_solaris_signal(0xfe0e8bd8, 0xf2001398, 0xf20010e0, 0x4000, 0x42ec, 0x0), at 0xfe1900e8 [10] __sighndlr(0xb, 0xf2001398, 0xf20010e0, 0xfe18f838, 0xf2001e14, 0xf2001e04), at 0xff36b82c
[11] sigacthandler(0xb, 0xf2001d70, 0x0, 0x0, 0x0, 0xff37e000), at 0xff368504
---- called from signal handler with signal 11 (SIGSEGV) ------
[12] jni_GetObjectField(0x35df24, 0x0, 0x1f2, 0xfe422000, 0xf2001144, 0x0), at 0xfe0e8bd8
[13] Java_sun_awt_SunToolkit_getPrivateKey(0x35df24, 0xf2001548, 0x0, 0xfbc15080, 0xf20011f0, 0x0), at 0xfbba5f34
[14] 0xfbc0bbc8(0x0, 0xf200163c, 0xf2001640, 0xffffffff, 0xfbc153e4, 0xf2001560), at 0xfbc0bbc7
[15] 0xfbc05b10(0x35de98, 0xb8, 0x3, 0xfbc15350, 0xf7d081d0, 0xf20015e0), at 0xfbc05b0f
[16] 0xfbc05c64(0xf38a5720, 0xf7b17250, 0x0, 0xfbc15350, 0xf3a00000, 0xf2001668), at 0xfbc05c63
[17] 0xfbc0612c(0xf38a6a50, 0x240, 0x3, 0xfbc154b0, 0xfbc15284, 0xf20016f8), at 0xfbc0612b
[18] 0xfbc05c64(0xf38a6a50, 0xb7, 0xf200188c, 0xfbc15030, 0x0, 0xf2001790), at 0xfbc05c63
[19] 0xfbc05c64(0xf38a6a50, 0xf781f808, 0xf2001904, 0xfbc151f0, 0x35de98, 0xf2001830), at 0xfbc05c63
[20] 0xfbc0612c(0xf2001908, 0x0, 0x0, 0xfbc154b0, 0x372f9c, 0xf20018a8), at 0xfbc0612b
[21] 0xfbc00118(0xf2001994, 0xf2001c08, 0xa, 0xf7820318, 0xfbc0aae0, 0xf2001b28), at 0xfbc00117
[22] JavaCalls::call_helper(0xf2001c00, 0xf2001a60, 0xf2001b20, 0x35de98, 0x35de98, 0xf2001a74), at 0xfe0bcaa4
[23] JavaCalls::call_virtual(0xfe422000, 0x35e038, 0xf2001b14, 0xf2001b10, 0xf2001b20, 0x35de98), at 0xfe0cd0c4
[24] JavaCalls::call_virtual(0xf2001c00, 0xf2001bfc, 0xf2001bf0, 0xf2001be8, 0xf2001be0, 0x35de98), at 0xfe0ccf24
[25] thread_entry(0x35de98, 0x35de98, 0x1ebb48, 0x35e038, 0x355354, 0xfe0ccb94), at 0xfe0cceac
[26] JavaThread::run(0x35de98, 0x0, 0x0, 0x0, 0x0, 0x0), at 0xfe0ccbbc
[27] _start(0x35de98, 0xff37f690, 0x1, 0x1, 0xff37e000, 0x0), at 0xfe0bb360
So in getPrivateKey function (src/solaris/natives/sun/awt/awt_MToolkit.c) line 2246,
/*
* Fix for BugTraq ID 4254701.
* Don't use Components and MenuComponents as keys in hash maps.
* We use private keys instead.
*/
if ((*env)->IsInstanceOf(env, obj, componentCls)) {
key = (*env)->GetObjectField(env, obj, componentIDs.privateKey);
} else if ((*env)->IsInstanceOf(env, obj, menuComponentCls)) {
key = (*env)->GetObjectField(env, obj, menuComponentIDs.privateKey);
}
it calls GetObjectField, somehow, the call makes JVM to generate a SIGSEGV. Reassign to AWT team to investigate this issue.
You may want to try and make a run with -Xcheck:jni passed in as a java arg for the applet. This will show if there is any native coding issues.
###@###.### 2002-09-18
instructions on how to pass the -Xcheck:jni to a plugin would be helpfull.
--------------------------------------------------------------------------
Unfortunately, it looks like the page has updated, and the applet is no
longer available. So, though the crash is not fixed, there is no way to
reproduce the bug.
We'll have to catch it next time, as for now, closing as not reproducible.
###@###.### 2002-10-23
I was unable to reproduce the bug with mozilla 1.2 from /home/kg and suntea. There might be some other settings that cause this crash. I need more details.
###@###.### 2003-01-10
###@###.### 2003-01-10
what version of solaris were you running?
do you already have a mozilla profile or did you try it with a new profile?
do you already have a java plugin in your .mozilla/plugin directory that
is overriding the one loaded by default in the kg version?
please feel free to log into my desktop (mcescher.eng) and try to reproduce
the problem from there. you could also copy my mozilla profile over. it's
at /home/edp/.mozilla/edp/52306bfq.slt in the .eng domain. if there's any
more info you need then please let me know what it is. this crash is very reproducible for me.
------------------
We already fixed this crash in Mantis(see 4739681), now we need to backport this fix into Hopper update.
###@###.### 2003-01-14
###@###.### 2003-01-14
bug 4739681 is the fix for the second assert failure in awt_TopLevel.c
the bugfix should be backported, but it's not the problem being followed
in this bug report. the problem being tracked by this bugreport is the
jvm crash due to a SIGSEGV.
also, what version numbers do Mantis and Hopper map to?
--------------
Yes, that's correct. There was also another fix that I think wasn't backported - 4696124 which might cause this kind of crash. Mantis is 1.4.2, Hopper is 1.4.1
###@###.### 2003-01-14
I was able to reproduce the problem with mozilla1.1 JRE1.4.1b21(plugin 1.4.1) and JRE1.4.2b12(plugin 1.4.1)
I was able to reproduce the problem wiht Netscape 7.0 JRE1.4.2b12(plugin 1.4.1)
I was unable to reproduce the bug with Netscape 7.0 JRE1.4.2b12(plugin 1.4.2) and JRE1.4.1_b01(plugin 1.4.2)
So, the problem is in plugin which corrupts the memory somehow and it was fixed in 1.4.2
###@###.### 2003-01-14
Reporter, can you verify that the bug has been fixed in 1.4.2?
###@###.### 2003-01-20
Not reproducible in 1.4.2 b13.
###@###.### 2003-01-21
###@###.### 2003-01-21
this bug is very reproducible in 1.4.1 and none of the customer calls are
agains 1.4.2 so i don't think this bug should be closed as "not reproducible"
i tried to reproduce the problem in 1.4.2-beta-b13 and here are my results.
there is no more crash but the suntea application refuses to load.
if i select yes in the security dialog windon i get an error dialog that
says "text/html returned!" if i hit reload i get the same error dialog.
there is nothing i can do to actually get the suntea application to come up.
so if the bug in this report is supposedly fixed in 1.4.2, then there is
another bug that is preventing suntea from displaying in the 1.4.2 jvm.
also in that case the fix should be backported to 1.4.2.
###@###.### 2003-01-21
I can launch Suntea using 1.4.2 b13 and Mozilla 1.2.1 successfully in Solaris.
###@###.### 2003-01-21
###@###.### 2003-01-21
have you tried the version of mozilla on /home/kg?
you can also try to reproduce the problem by running from my desktop mcescher.eng
###@###.### 2003-01-21
I ran from /home/kg which is using 1.4.1_01. Suntea was launched successfully. I also run from my own 1.2.1 build in Solaris with 1.4.2 b13, both runs successfully.
###@###.### 2003-01-21
i talked with xiaobin on the phone and we managed to reproduce the problem
in 1.4.1. he also helped me with getting suntea working with 1.4.2 and
my mozilla configuration. (initially 1.4.2 was not working with my version
of mozilla due to my proxy settings. there is a seperate bug filed on this.
4805914)
after talking with him he informed me that since this problem is already
fixed in 1.4.2 we should use that version. 1.4.2 has not shipped yet and
1.4.1 is already in sustaining mode, so unless we escelate the issue or a customer hits the bug it will not be fixed in 1.4.1
###@###.### 2003-01-24
The bug has been fixed in 1.4.2 now. And the reporter filed another bug against the "text/html" issue.
Close this bug as "Not reproducible". It can't be reprouced in 1.4.2.