Closed Bug 230083 Opened 22 years ago Closed 20 years ago

index out of bounds crash

Categories

(Core Graveyard :: Java: OJI, defect)

Product:
Core Graveyard
Component:
Java: OJI
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: u123541, Assigned: yuanyi21)

References

(
URL
)

Details

(Keywords: crash)

Attachments

(3 files)

screenshot of initial applet window
22.08 KB, image/png
Details
session log 04/29/04
3.79 KB, text/plain
Details
diff -u of prefs.js
10.78 KB, text/plain
Details
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031210 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6b) Gecko/20031210 This bug has been plaguing me since I first tried to use Java on Mozilla 1.4... $ INTERNAL ERROR on Browser End: Plugin instance index out of bounds 13605 System error?:: Resource temporarily unavailable [2]+ Exit 255 /usr/local/mozilla/mozilla My only use for java was to use it for Ameritrade/Datek's Streamer; but I always get a crash within 2 minutes of starting the Streamer. Reproducible: Always Steps to Reproduce: 1.Login to ameritrade.com 2.start Streamer 3.start applets Actual Results: 1. Browser window(s) disappear 2. Applet windows disappear shortly after This *always* happens with 2 minutes at most.... I've been trying various versions of Mozilla and java to get around this problem, to no avail... I've only tried to use java on ameritrade.com and I won't make my trading account available for verification... :) Seriously, this has financial implications as I can't rely on Mozilla to trade...
can you load any java applets? what does this bug have to do with "index out of bounds"
Keywords: crash
Here's what I just got after logging in to ameritrade.com, starting the Streamer, selecting the following applets from the menu applet: Index: small applet window popped up Portfolio: immediate death of the browser $ strace -ffo mb /usr/local/mozilla/mozilla INTERNAL ERROR on Browser End: Plugin instance index out of bounds 21541 System error?:: Resource temporarily unavailable > what does this bug have to do with "index out of bounds" Umm... can you explain that question...? What I see is the browser dying first with "Plugin instance index out of bounds N" -- does this mean the browser is complaining about a plugin error; or is the browser failing, trying to handle a plugin request..? Background: I never enabled Java on any browser until it was the only way I could make use of a service requiring it... I'm running Mandrake Linux 9.2, where my initial thought was that Mozilla might have a binary incompatability with Sun's Java based on the different compiler levels: # Mozilla 1.4, Copyright (c) 2003 mozilla.org, build 2003063000 # (built with gcc version 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)) # /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so I've been trying to solve this with various JVMs; but all combinations I've tried crash the same way... I then decided to try 1.6b since that was my only chance at reporting this bug.... Since I ran strace this time, is there anything you would be interested in? I have ulimit -c set to unlimited; yet, no core was dumped. Watching the processes with: $ while true; do clear; ll mb*; sleep 1; done The only 2 processes created after Java started gave only this info: mb.28377: --- SIGSTOP (Stopped (signal)) @ 0 (0) --- modify_ldt(1, {entry_number:7, base_addr:0x4242dbe0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_ pages:1, seg_not_present:0, useable:1}, 16) = 0 getpid() = 28377 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 sched_setscheduler(0x6ed9, 0, 0x4242dcf8) = 0 poll([{fd=32, events=POLLRDNORM, revents=POLLRDNORM}], 1, -1) = 1 write(5, "\372", 1) = 1 rt_sigprocmask(SIG_SETMASK, NULL, [RTMIN], 8) = 0 rt_sigsuspend([] <unfinished ...> --- SIGRTMIN (Unknown signal 32) @ 0 (0) --- mb.28378: --- SIGSTOP (Stopped (signal)) @ 0 (0) --- modify_ldt(1, {entry_number:8, base_addr:0x4262dbe0, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_ pages:1, seg_not_present:0, useable:1}, 16) = 0 getpid() = 28378 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 sched_setscheduler(0x6eda, 0, 0x4262dcf8) = 0 poll([{fd=36, events=POLLRDNORM}], 1, -1) = -1 EINTR (Interrupted system call) --- SIGRT_1 (Unknown signal 33) @ 0 (0) --- exit_group(-1) = ? The process which was the most active (activity, not verbosity) logging strace data, ended with: mb.28111: poll([{fd=8, events=POLLIN}], 1, 2000) = 0 getppid() = 28104 poll([{fd=8, events=POLLIN}], 1, 2000) = 0 getppid() = 28104 poll([{fd=8, events=POLLIN, revents=POLLIN}], 1, 2000) = 1 getppid() = 28104 read(8, "`0\17@\2\0\0\0\377\377\377\377\340\233p\10p\302+@0\201"..., 148) = 148 kill(28378, SIGRT_1) = 0 kill(28377, SIGRT_1) = 0 --- SIGRT_1 (Unknown signal 33) @ 0 (0) --- sigreturn() = ? (mask now ~[TRAP KILL STOP]) --- SIGRT_1 (Unknown signal 33) @ 0 (0) --- sigreturn() = ? (mask now ~[TRAP KILL STOP]) kill(28113, SIGRT_1) = 0 --- SIGRT_1 (Unknown signal 33) @ 0 (0) --- sigreturn() = ? (mask now ~[TRAP KILL STOP]) kill(28112, SIGRT_1) = 0 --- SIGRT_1 (Unknown signal 33) @ 0 (0) --- sigreturn() = ? (mask now ~[TRAP KILL STOP]) waitpid(28378, NULL, __WCLONE) = 28378 waitpid(28377, NULL, __WCLONE) = 28377 waitpid(28113, NULL, __WCLONE) = 28113 waitpid(28112, NULL, __WCLONE) = 28112 kill(28104, SIGRTMIN) = 0 exit_group(0) = ? While the main process ended with: mb: rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0 rt_sigaction(SIGINT, {0x8076710, [], SA_RESTORER, 0x40057ca8}, {SIG_DFL}, 8) = 0 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigaction(SIGINT, {SIG_DFL}, {0x8076710, [], SA_RESTORER, 0x40057ca8}, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 stat64("/usr/bin/md5sum", {st_mode=S_IFREG|0755, st_size=32056, ...}) = 0 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 stat64("core", 0xbfffedf0) = -1 ENOENT (No such file or directory) rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [INT CHLD], [RTMIN], 8) = 0 fork() = 28104 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [RTMIN], 8) = 0 rt_sigaction(SIGINT, {0x8076710, [], SA_RESTORER, 0x40057ca8}, {SIG_DFL}, 8) = 0 waitpid(-1, [WIFEXITED(s) && WEXITSTATUS(s) == 255], 0) = 28104 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, 0xbfffed2c, WNOHANG) = -1 ECHILD (No child processes) sigreturn() = ? (mask now [RTMIN]) rt_sigaction(SIGINT, {SIG_DFL}, {0x8076710, [], SA_RESTORER, 0x40057ca8}, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 stat64("core", 0xbffff010) = -1 ENOENT (No such file or directory) rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 read(255, "\nexit $exitcode\n", 8176) = 16 rt_sigprocmask(SIG_BLOCK, NULL, [RTMIN], 8) = 0 rt_sigprocmask(SIG_SETMASK, [RTMIN], NULL, 8) = 0 exit_group(255) = ? I'm very interested in getting a working combination, so let me know how I can help...
[I thought I'd already posted this update... it's not showing up, so re-entering...] Created a new userid, started 1.6b -- oops... forgot the plugin symlink -- restarted 1.6b and with otherwise virgin .mozilla/, got: $ INTERNAL ERROR on Browser End: Plugin instance index out of bounds 12581 System error?:: Resource temporarily unavailable [1]+ Done strace -fftto mb1 /usr/local/mozilla/mozilla
Without a valid account, I can't reproduce this problem. And I can't find any clue from the trace log. Reporter, can you load any other java applet successfully?
Ran the tests just fine at: http://www.w3.org/People/mimasa/test/object/java/ http://www.leinweb.com/snackbar/hp/ Is there some debugging I can try...? Just installed ssldump; but I haven't been able to get any output from that yet... Will upload a screenshot of Streamer initial applet window. As soon as I clicked on the "Streamer" button, moz died...
Doing some more digging... $ ldd /usr/local/mozilla/mozilla-bin libmozjs.so => not found <============ libplds4.so => /usr/lib/libplds4.so (0x40028000) libplc4.so => /usr/lib/libplc4.so (0x4002b000) libnspr4.so => /usr/lib/libnspr4.so (0x40030000) libpthread.so.0 => /lib/i686/libpthread.so.0 (0x40067000) libdl.so.2 => /lib/libdl.so.2 (0x400b7000) libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x400ba000) libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x40200000) libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x4023a000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4023d000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40264000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4026c000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4027b000) libm.so.6 => /lib/i686/libm.so.6 (0x4035e000) libc.so.6 => /lib/i686/libc.so.6 (0x40381000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) Yet.... $ ll /usr/local/mozilla/libmozjs* -rwxrwxrwx 1 root root 525416 Dec 10 14:02 libmozjs.so* Grep'ing the latest strace files: $ grep libmozjs mb2* mb2.21366:22:33:03.892777 open("/usr/local/mozilla/i686/sse/mmx/libmozjs.so", O_RDONLY) = -1 ENOENT (No such file or directory) mb2.21366:22:33:03.892957 open("/usr/local/mozilla/i686/sse/libmozjs.so", O_RDONLY) = -1 ENOENT (No such file or directory) mb2.21366:22:33:03.893127 open("/usr/local/mozilla/i686/mmx/libmozjs.so", O_RDONLY) = -1 ENOENT (No such file or directory) mb2.21366:22:33:03.893354 open("/usr/local/mozilla/i686/libmozjs.so", O_RDONLY) = -1 ENOENT (No such file or directory) mb2.21366:22:33:03.893522 open("/usr/local/mozilla/sse/mmx/libmozjs.so", O_RDONLY) = -1 ENOENT (No such file or directory) mb2.21366:22:33:03.893692 open("/usr/local/mozilla/sse/libmozjs.so", O_RDONLY) = -1 ENOENT (No such file or directory) mb2.21366:22:33:03.893859 open("/usr/local/mozilla/mmx/libmozjs.so", O_RDONLY) = -1 ENOENT (No such file or directory) mb2.21366:22:33:03.894026 open("/usr/local/mozilla/libmozjs.so", O_RDONLY) = 3 So moz does find it at run time... even ran ldconfig and it still dies... $ ldd /usr/local/mozilla/mozimozilla-bin libmozjs.so => not found ... I'm puzzled...
That's why you can't start mozilla with "mozilla-bin". The mozilla & run-mozilla.sh script will make the environment ready for run mozilla-bin.
Umm... I _never_ said I started mozilla with mozilla-bin... to see why I even mentioned mozilla-bin, issue "ldd /usr/local/mozilla/mozilla"... Hint: $ ldd /usr/local/mozilla/mozilla not a dynamic executable
I was trying to explain why the libmozjs.so is missing from the ldd command but mozilla is still able to run - that's because you start mozilla via a script called "mozilla", and it will execute another script called "run-mozilla.sh", the later will set some environment variable, for example, add the directory where the mozilla-bin is located to LD_LIBRARY_PATH, then mozilla-bin will be able to find proper libraries.
That was my understanding too... so why, with a fresh install, and the "missing" lib in the same directory with everything else, is this the only lib not found...? This lib not found is a problem; but I'm beginning to doubt it's the real dying problem since moz does have it open according to lsof. Still open to suggestions for trapping this bug....
There is only one lib missing is because you have another mozilla installed in your system. Otherwise, ldd won't able to found the following 3 libs: libplds4.so, libplc4.so, libnspr4.so, too. Anyway, the ldd problem is absolutely not related to this bug. The best way to catch the bug is to have your own debug build, and run it in gdb. A stack dump will be very helpful.
argh! Compiled moz from CVS -- now I'm off to look for PSM...
Trying to debug this problem with gdb 6.0 (sometimes with ddd 3.3.6) on latest CVS, and as long as gdb is involved, mozilla won't finish starting.... spins its wheels a lot chewing ~14-18% CPU; but never gets to put up more than an empty X window (no moz contents)... Ideas?
you can let mozilla start up first, then just before the crash occurred, start gdb and attach the mozilla-bin process (using ps command to find the pid). you will be able to see the stack when mozilla crashed.
sigh... this is not going to be easy... When I fire up Streamer(tm), I get loads of java_vms: $ /sbin/pidof java_vm 18102 18101 17931 17872 17871 17864 17861 17860 17859 17856 17853 17852 17851 17849 17847 17846 17845 17844 17843 17842 17841 17840 17839 I'll work my way through them eventually... so far, gdb catches signal 32 a lot and I do a bt and cont which provides no useful info (see below)... then, when the problem occurs, there is no bt stack. I did notice something however... if I start the Index applet first, all seems to work; but if I start Streamer and/or Portfolio, then Index, it immediately dies... (gdb) c Continuing. Program received signal SIG32, Real-time event 32. 0x40030714 in ?? () (gdb) bt #0 0x40030714 in ?? () #1 0x4db5356c in ?? () #2 0x400302b8 in ?? () #3 0x4db534d4 in ?? () #4 0x00000020 in ?? () #5 0x4db534d4 in ?? () #6 0x4db534f0 in ?? () #7 0x00000004 in ?? () (gdb) c Continuing. Program received signal SIG32, Real-time event 32. 0x40030714 in ?? () (gdb) bt #0 0x40030714 in ?? () #1 0x4db5356c in ?? () #2 0x400302b8 in ?? () #3 0x4db534d4 in ?? () #4 0x00000020 in ?? () #5 0x4db534d4 in ?? () #6 0x4db534f0 in ?? () #7 0x00000004 in ?? () (gdb) c Continuing. warning: Child process unexpectedly missing: No child processes Program terminated with signal ?, Unknown signal. The program no longer exists. (gdb) bt No stack. (gdb) Note that even though gdb says the prog no longer exists, the vm I'm attached to is the only process still hanging around -- I have to issue "kill -9 <pid>" to get the 3 applet windows to close. Still digging....
OK... this time, I noticed some mozilla-bin processes which started after some java_vm processes, so I attached to the last one started, then opened Streamer, then Index and got this backtrace... [snip symbol stuff] 0x405d5546 in poll () from /lib/i686/libc.so.6 (gdb) c Continuing. Program received signal SIG33, Real-time event 33. 0x405d5546 in poll () from /lib/i686/libc.so.6 (gdb) bt #0 0x405d5546 in poll () from /lib/i686/libc.so.6 #1 0x4364ab22 in QueueRunnable::waitOnPipe() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #2 0x4364ac11 in QueueRunnable::threadEntry(void*) () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #3 0x401023dc in _pt_root (arg=0x8b2cdd8) at ptthread.c:214 #4 0x4012c600 in pthread_detach () from /lib/i686/libpthread.so.0 #5 0x405dda37 in clone () from /lib/i686/libc.so.6 (gdb) Does this help..? I'll try attaching to the other mozilla-bin now...
Now, I don't know what triggers the crash... this time, it died when I closed the Index applet... (I inserted some comments in the gdb console as I did things (see inline)... the common thing I see at the time of hte crash is SIG33... I'm not sure how to proceed from here... hope these backtraces help... 0x405d5546 in poll () from /lib/i686/libc.so.6 (gdb) c Continuing. Program received signal SIG32, Real-time event 32. 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 (gdb) bt #0 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #1 0x4012e2b8 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #2 0x4012acd0 in pthread_cond_wait () from /lib/i686/libpthread.so.0 #3 0x400fae6b in PR_WaitCondVar (cvar=0x82f3f60, timeout=4294967295) at ptsynch.c:389 #4 0x400fb5be in PR_Wait (mon=0x82f3fa0, timeout=4294967295) at ptsynch.c:568 #5 0x4364abd0 in QueueRunnable::waitOnPipe() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #6 0x4364ac11 in QueueRunnable::threadEntry(void*) () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #7 0x401023dc in _pt_root (arg=0x8adf008) at ptthread.c:214 #8 0x4012c600 in pthread_detach () from /lib/i686/libpthread.so.0 #9 0x405dda37 in clone () from /lib/i686/libc.so.6 (gdb) c Continuing. Program received signal SIG32, Real-time event 32. 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 (gdb) bt #0 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #1 0x4012e2b8 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #2 0x4012acd0 in pthread_cond_wait () from /lib/i686/libpthread.so.0 #3 0x400fae6b in PR_WaitCondVar (cvar=0x82f3f60, timeout=4294967295) at ptsynch.c:389 #4 0x400fb5be in PR_Wait (mon=0x82f3fa0, timeout=4294967295) at ptsynch.c:568 #5 0x4364abd0 in QueueRunnable::waitOnPipe() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #6 0x4364ac11 in QueueRunnable::threadEntry(void*) () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #7 0x401023dc in _pt_root (arg=0x8adf008) at ptthread.c:214 #8 0x4012c600 in pthread_detach () from /lib/i686/libpthread.so.0 #9 0x405dda37 in clone () from /lib/i686/libc.so.6 (gdb) c Continuing. Program received signal SIG32, Real-time event 32. 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 (gdb) bt #0 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #1 0x4012e2b8 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #2 0x4012acd0 in pthread_cond_wait () from /lib/i686/libpthread.so.0 #3 0x400fae6b in PR_WaitCondVar (cvar=0x82f3f60, timeout=4294967295) at ptsynch.c:389 #4 0x400fb5be in PR_Wait (mon=0x82f3fa0, timeout=4294967295) at ptsynch.c:568 #5 0x4364abd0 in QueueRunnable::waitOnPipe() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #6 0x4364ac11 in QueueRunnable::threadEntry(void*) () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #7 0x401023dc in _pt_root (arg=0x8adf008) at ptthread.c:214 #8 0x4012c600 in pthread_detach () from /lib/i686/libpthread.so.0 #9 0x405dda37 in clone () from /lib/i686/libc.so.6 (gdb) c Continuing. Program received signal SIG32, Real-time event 32. 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 (gdb) bt #0 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #1 0x4012e2b8 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #2 0x4012acd0 in pthread_cond_wait () from /lib/i686/libpthread.so.0 #3 0x400fae6b in PR_WaitCondVar (cvar=0x82f3f60, timeout=4294967295) at ptsynch.c:389 #4 0x400fb5be in PR_Wait (mon=0x82f3fa0, timeout=4294967295) at ptsynch.c:568 #5 0x4364abd0 in QueueRunnable::waitOnPipe() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #6 0x4364ac11 in QueueRunnable::threadEntry(void*) () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #7 0x401023dc in _pt_root (arg=0x8adf008) at ptthread.c:214 #8 0x4012c600 in pthread_detach () from /lib/i686/libpthread.so.0 #9 0x405dda37 in clone () from /lib/i686/libc.so.6 (gdb) c Continuing. ### Portfolio applet now running ### firing up Index applet Program received signal SIG32, Real-time event 32. 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 (gdb) ### applet now running (gdb) ### firing up Index applet (gdb) bt #0 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #1 0x4012e2b8 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #2 0x4012acd0 in pthread_cond_wait () from /lib/i686/libpthread.so.0 #3 0x400fae6b in PR_WaitCondVar (cvar=0x82f3f60, timeout=4294967295) at ptsynch.c:389 #4 0x400fb5be in PR_Wait (mon=0x82f3fa0, timeout=4294967295) at ptsynch.c:568 #5 0x4364abd0 in QueueRunnable::waitOnPipe() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #6 0x4364ac11 in QueueRunnable::threadEntry(void*) () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #7 0x401023dc in _pt_root (arg=0x8adf008) at ptthread.c:214 #8 0x4012c600 in pthread_detach () from /lib/i686/libpthread.so.0 #9 0x405dda37 in clone () from /lib/i686/libc.so.6 (gdb) c Continuing. ### argh... this time applets are still running... ### firing up Streamer applet Program received signal SIG32, Real-time event 32. 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 (gdb) ### argh... this time applets are still running... (gdb) ### firing up Streamer applet (gdb) bt #0 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #1 0x4012e2b8 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #2 0x4012acd0 in pthread_cond_wait () from /lib/i686/libpthread.so.0 #3 0x400fae6b in PR_WaitCondVar (cvar=0x82f3f60, timeout=4294967295) at ptsynch.c:389 #4 0x400fb5be in PR_Wait (mon=0x82f3fa0, timeout=4294967295) at ptsynch.c:568 #5 0x4364abd0 in QueueRunnable::waitOnPipe() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #6 0x4364ac11 in QueueRunnable::threadEntry(void*) () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #7 0x401023dc in _pt_root (arg=0x8adf008) at ptthread.c:214 #8 0x4012c600 in pthread_detach () from /lib/i686/libpthread.so.0 #9 0x405dda37 in clone () from /lib/i686/libc.so.6 (gdb) c Continuing. ### still running... ### closing Index Program received signal SIG32, Real-time event 32. 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 (gdb) ### still running... (gdb) ### closing Index (gdb) bt #0 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #1 0x4012e2b8 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #2 0x4012acd0 in pthread_cond_wait () from /lib/i686/libpthread.so.0 #3 0x400fae6b in PR_WaitCondVar (cvar=0x82f3f60, timeout=4294967295) at ptsynch.c:389 #4 0x400fb5be in PR_Wait (mon=0x82f3fa0, timeout=4294967295) at ptsynch.c:568 #5 0x4364abd0 in QueueRunnable::waitOnPipe() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #6 0x4364ac11 in QueueRunnable::threadEntry(void*) () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #7 0x401023dc in _pt_root (arg=0x8adf008) at ptthread.c:214 #8 0x4012c600 in pthread_detach () from /lib/i686/libpthread.so.0 #9 0x405dda37 in clone () from /lib/i686/libc.so.6 (gdb) c Continuing. Program received signal SIG33, Real-time event 33. 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 (gdb) bt #0 0x4012e714 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #1 0x4012e2b8 in pthread_getconcurrency () from /lib/i686/libpthread.so.0 #2 0x4012acd0 in pthread_cond_wait () from /lib/i686/libpthread.so.0 #3 0x400fae6b in PR_WaitCondVar (cvar=0x82f3f60, timeout=4294967295) at ptsynch.c:389 #4 0x400fb5be in PR_Wait (mon=0x82f3fa0, timeout=4294967295) at ptsynch.c:568 #5 0x4364abd0 in QueueRunnable::waitOnPipe() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #6 0x4364ac11 in QueueRunnable::threadEntry(void*) () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #7 0x401023dc in _pt_root (arg=0x8adf008) at ptthread.c:214 #8 0x4012c600 in pthread_detach () from /lib/i686/libpthread.so.0 #9 0x405dda37 in clone () from /lib/i686/libc.so.6 (gdb)
Pierre, thanks for digging this deep. You have to skip all the SIG32/SIG33 breaks (just "c" when it stopped by SIG32/33), the backtrace stack is meaningless at that time, it's not the real crash. Another way to debug this: let your debug-build mozilla run alone (without gdb), until it crashed. Usually, you will see a stack dump in the console window, and at the last line, it will tell you a pid which will be attached in gdb. Then you can start gdb and attach that pid, execute "bt" to see the stack.
Can you save me some time? I'm not sure where and how to turn on this debugging (there's so much to choose from)... of course, I still don't know if it's moz or the jvm that's dying, so any tips on enabling debug for both would be appreciated... Thanks.
> Another way to debug this: let your debug-build mozilla run alone (without > gdb), until it crashed. Usually, you will see a stack dump in the console > window, and at the last line, it will tell you a pid which will be attached in > gdb. Then you can start gdb and attach that pid, execute "bt" to see the > stack. That's not going to work with the "INTERNAL ERROR on Browser End:". That message indicates that java plugin detected a problem and called exit(). The Mozilla debug mechanism has no way to catch this. In addition to continuing after the SIG32/33, you need to do (gdb) b exit so that when the plugin jumps ship, gdb will know to catch it. Otherwise, gdb will just let Mozilla exit.
Pierre, you can just try what Andrew said - start mozilla->start gdb->(gdb)attach mozilla-bin process->(gdb)b exit->(gdb)cont->(gdb) skip all SIG32/33->mozilla/jvm crash->(gdb)break at exit->(gdb)bt->post the stack here. Judging from the output you posted in comment 0, it's definitely a jvm crash, not a mozilla crash.
Much better... here's the bt... (from a fresh CVS compile) BTW, I tried with KDE's Konqueror and I haven't seen a crash with Konq yet. Another tidbit: I noticed that mozilla complains about Ameritrade's CSS -- sure enough; W3C's CSS validator confirms the errors which I reported to Ameritrade's techhelp... HTH... Breakpoint 1, 0x4052e216 in exit () from /lib/i686/libc.so.6 (gdb) bt #0 0x4052e216 in exit () from /lib/i686/libc.so.6 #1 0x4363e61c in plugin_error () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #2 0x436439ed in JavaPluginFactory5::GetInstance(int) () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #3 0x43645900 in JavaVM5::DoWork() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #4 0x43643fbb in JavaVM5::ProcessWorkQueue() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #5 0x43643e57 in worker_queue_processor(void*) () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #6 0x4363eae4 in QueueRunnable::Run() () from /usr/java/j2re1.4.2_03/plugin/i386/ns610-gcc32/libjavaplugin_oji.so #7 0x40b87252 in handleRunnableEvent (aEvent=0x8af9e28) at nsJVMManager.cpp:288 #8 0x407fe3d0 in PL_HandleEvent (self=0x8af9e28) at plevent.c:671 #9 0x407fe271 in PL_ProcessPendingEvents (self=0x8158ec8) at plevent.c:606 #10 0x40800804 in nsEventQueueImpl::ProcessPendingEvents() (this=0x815c790) at nsEventQueue.cpp:391 #11 0x413ebd62 in event_processor_callback (data=0x815c790, source=5, condition=GDK_INPUT_READ) at nsAppShell.cpp:187 #12 0x413eb6cd in our_gdk_io_invoke (source=0x81bdb28, condition=G_IO_IN, data=0x81859d8) at nsAppShell.cpp:72 #13 0x4030cf45 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0 #14 0x00000001 in ?? () #15 0x081859d8 in ?? () #16 0x4030e92a in g_get_current_time () from /usr/lib/libglib-1.2.so.0 #17 0x0824ea80 in ?? () #18 0xbffff3c0 in ?? () #19 0x081859d8 in ?? () #20 0x402f8248 in ?? () from /usr/lib/libgdk-1.2.so.0 #21 0x4032276c in ?? () from /usr/lib/libglib-1.2.so.0 #22 0x4030cf20 in g_io_add_watch () from /usr/lib/libglib-1.2.so.0 #23 0x403222e8 in ?? () from /usr/lib/libglib-1.2.so.0 Hmmm.... my CPU is running at 99% and a quick check shows a LOT of jvms running... # pidof java_vm 31840 31839 31838 31837 31836 31835 31834 31832 31820 31812 31810 31791 31784 31782 31779 31774 31769 31767 31764 31758 31757 31750 31747 31741 31737 31725 31719 31705 31687 31683 31681 31679 31677 31672 31658 31657 31654 31652 31650 31627 31622 31611 31609 31606 31604 31595 31594 31584 31580 31575 31562 31556 31550 31536 31529 31521 31517 31516 31503 31490 31488 31486 31474 31472 31461 31456 31452 31447 31446 31439 31433 31432 31424 31423 31420 31413 31405 31397 31394 31390 31383 31382 31380 31376 31373 31366 31363 31355 31351 31342 31340 31338 31333 31328 31324 31321 31320 31318 31314 31308 31305 31299 31292 31290 31278 31276 31274 31266 31260 31252 31247 31242 31240 31230 31226 31219 31208 31196 31186 31184 31180 31179 31175 31172 31171 31166 31159 31155 31151 31146 31140 31136 31132 31124 31123 31120 31116 31112 31105 31099 31096 31093 31088 31079 31078 30906 30848 30847 30840 30837 30836 30835 30833 30830 30829 30827 30825 30823 30822 30821 30820 30819 30818 30817 30816 30815 and still growing at a rate of one every ~2 seconds.... as soon as I quit gdb, they all went away...
Confirmed. Xiaobin, are you familiar with this kind of JPI error? I've seen this once today, but no longer reproducible now.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I think we fixed several this kinds of error in 1.5. Kyle, would you try to reproduce using 1.5?
I first encountered this bug in 1.5 (included in Mandrake Linux 9.2 distro); never used java before then.... that's why I proceeded to 1.6b, then CVS -- all of which have this bug.
Pierre, Xiaobin meant JRE 1.5 which hasn't been officially released yet, not mozilla 1.5. Xiaobin, I've never successfully reproduced this bug (the test site needs a valid account), that why I ask Pierre to do the debugging work. Thanks, Pierre.
Ah... just looked around the java sites and can only find "coming soon" links... even the developer pages don't seem to have just the jvm... got a pointer, or some other way for me to get access to 1.5...? I'd hate to see it come out with this bug still there... FYI... I just did a quick test with my wife's new Ameritrade account -- funds not yet transferred from previous brokerage house. The applets came up fine and I could stop/restart them, until... on the [empty] portfolio applet, I entered a ticker symbol, and as soon as I clicked the applet's Add button, everything died... got other stuff to do today, so I'll try to attach gdb later... in the meanwhile, a link to 1.5 would be nice... thanks for your help!
Running today's CVS and I'm not seeing the crashes any more -- so far... will try to do more testing later this week...
Pierre, you can go to this site to obtain a j2sdk1.5 alpha build: http://java.sun.com/developer/earlyAccess/j2sdk150_alpha/
Hi Kyle, Been trying it out for a few minutes... not dying yet... the fonts and character locations look much better. The only thing that puzzles me is when first starting Streamer, I don't get my portfolio contents... started several other applets from the Ameritrade site, all without content... closed them all down, and without restarting moz, fired up Streamer applet again and got the data this time... On the whole, MUCH better... looks like this bug may have been resolved in a previous CVS around 01/20/04... I'll update to the latest CVS tonight and recheck... From what I see now, we can close this bug and I'll open new ones on the other issues if I can figure out their cause... Thanks!
Pierre, thanks for the verification and digging this so deep. "FIXED" is not very accurate word for the close reason, but it's a little better than others (WONTFIX, INVALID, WFM).
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
> "FIXED" is not very accurate word for the close reason, but it's a little > better than others Actually, it's not. If you can't point to a checked in bug or patch that fixed something (and it's not Tech Evangelism), and what didn't work before now does, then WORKSFORME is the appropriate resolution.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WORKSFORME
Q: wouldn't WORKSFORME imply that someone else could not reproduce the problem...? This was a very reproducible problem** that disappeared from the CVS version around 01/19-20/04. My switch to java 1.5 yesterday did not change the fact that the problem had already disappeared over 2 weeks ago. ** The only reason no one else could test is that a stock trading account is required... Of course, I also reported problems with the web site and I'm not currently seeing as much non-compliance to standards in those pages... so, the actual "fix" may have been accomplished by web site changes, which would imply that this bug may still be lurking in the code. Too bad we don't have these codes available: DISAPPEARED, NOTFOUND, POSSIBLETIMEBOMB, WATCHFOR,... Anyway, THANKS for the help trying to locate it, even if we didn't nail it.
This bug appeared to be resolved while using a test userid... now that I am trying to use my normal userid again, this problem persists. I copied over the test userid's prefs.js file and lo and behold, it appears to have stopped dying... this implies there may be something in the old (and larger) prefs.js that is triggering this problem... which diff format would best help? diff -u seems reasonable; but let me know...
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Is this still reproducible if you create a new profile and use your normal userid? I'm not sure if the difference between prefs.js is helpful, but if you want, please make it using diff -u and upload as an attachment to this bug.
Mozilla 1.8a Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a) Gecko/20040429 Not sure when in the past couple of weeks (I haven't used Ameritrade recently) this bug returned; but it's back... Attaching the entire console log from start to crash... Will try to find time to dig further...
Attached file session log 04/29/04 —
OK... fired up same binary in another account and that one doesn't crash... Attaching diff -u of both prefs.js files... "pierre" works, "pfortin" crashes. This (see attachment) is weird... unless the version gets written when moz is closed... -user_pref("browser.startup.homepage_override.mstone", "rv:1.7b"); +user_pref("browser.startup.homepage_override.mstone", "rv:1.8a");
Attached file diff -u of prefs.js —
ARGHHHHHH!!!! pfortin is using libjavaplugin_oji.so Java(TM) Plug-in 1.4.2_03 pierre is using libjavaplugin_oji.so Java(TM) Plug-in 1.5.0 Ignore today's updates to this bug :^P
Pierre, are you still seeing this bug using the most recent mozilla/firefox and jre?
This appears to have been resolved by release 1.5 of java... thanks!
okay, WFM per comment 43.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: