ComponentManager::AutoRegister and instead using patch v2 from 87913 which
adds a new function rather than changing the existing one. r=mstoltz, dveditz.
Subject:
Fatal error executing in IBM J9 VM
Resent-Date:
Mon, 9 Jul 2001 15:35:32 -0700 (PDT)
Resent-From:
mozilla-jseng@mozilla.org
Date:
9 Jul 2001 15:33:38 -0700
From:
bdemchak@tpsoft.com (Barry Demchak)
Organization:
http://groups.google.com/
To:
mozilla-jseng@mozilla.org
Newsgroups:
netscape.public.mozilla.jseng
Hi --
I've encountered an error in either Rhino or the IBM J9 VM's runtime
support -- I'm not sure which -- but the end result is an unhandled
exception. I'm quite willing to believe that it's already been dealt
with. If so, will someone point me to the solution?
I'm using: IBM's J9 on Windows 2000,
IBM's IDE v1.3 on Windows 2000,
Rhino v1.5 from mozilla.org
The exception is java.lang.StringIndexOutOfBoundsException.
It occurs in Context.getSourcePositionFromStack just after the call to
RuntimeException.printStackTrace. The code is expecting a code
reference that looks something like "(Example.js:50)" where "50" is
the line number. (I gather that's what the Sun VM returns???)
Instead, J9 is returning a code reference that looks like:
"java.lang.RuntimeException\n\n\n\nStack trace:\n\n
java/lang/Throwable.<int>()V\n\n" etc, etc, etc.
The error occurs because the Colon variable's value is less than the
Open variable's value in Context.getSourcePositionFromStack. When the
s.substring is evaulated, there's a negative string length ... boom.
I've patched an "if" statement in the getSourcePositionFromStack code
so that instead of:
if (c == '\n' && open != -1 && close != -1 && colon != -1)
I have:
if (c == '\n' && open != -1 && close != -1 && colon != -1 && open <
colon && colon < close)
Certainly, there's a better fix, but it's sufficient to keep me going.
So, I have several questions ... being new to open source and this
forum:
1) Is this a real bug ... a real Rhino bug??
2) Has this already been found?
3) Has this already been fixed?
4) If not, what's the proper protocol for reporting it?
5) What's the proper protocol for fixing it?
This shows up *very* quickly when trying to run a script under J9.
When it occurs, Rhino is trying to issue a warning about some shady
JavaScript code.
If this is a real bug and hasn't been fixed, I would infer that there
aren't a lot of people trying to run this under J9. Would that be a
fair statement? If so, can anyone comment as to why that would be??
Thanks!
Rhino: Fixes for catch in Interpreter.interpret
Date:
Wed, 11 Jul 2001 19:06:46 +0200
From:
Igor Bukanov <igor@icesoft.no>
Organization:
Wind River
To:
Norris Boyd <nboyd@atg.com>
Hi, Norris!
When doing that instruction counting implementation, I managed to mess
up code in the catch statement in Interpreter.interpret.
First for some reason I assumed that for a general RuntimeException the
previous code do not run finally statements but only script catch code.
Of cause this was wrong: that code skipped catch for arbitrary exception
while calling finally.
This is a reasonable behavior especially given the fact that arbitrary
RuntimeException may only arise from, say, bugs, other exceptions should
be wrapped to JavaScriptException.
Second I removed calls to debug.handleExceptionThrown...
The attached patch restores the original catch/finally logic and re-adds
calls to debug.handleExceptionThrown.
I will later update it that catch to handle Error as well to allow
cleanup after throwing an Error instance from
Context.observeInstructionCount , but restoration should go first.
Regards, Igor
preflight the date picker with today's date.
there is no date picker yet, but there is a simple xul textbox.
d/m/yyyy is the supported format. there are plans to implement
a date picker in XBL which prevent user error. right now, a user
could type "foobar" for the date.
r=timeless, sr=bienveu
when I fixed the crasher (by going from keeping the bundle as a static COMPtr to member variable)
I forgot to remove the code that only allocated one bundle. this caused it to assert
when there were two or more nsMsgStatusFeedBack instances, and worse, they other instances
wouldn't work.
r=varada, sr=bienvenu
