Question about uncaught exceptions

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about uncaught exceptions

ISHIKAWA,chiaki
Hi,

Thunderbird occasionally sees these mysterious exceptions
which are logged in its error console.

uncaught exception: 2147500037
uncaught exception: 2153578497

At least these are also generated
during |make mozmill| test suite run of C-C TB sometimes (not always, I think).

However, analyzing these uncaught exceptions has been very difficult and has
been put on back burner for more than two years for obvious reasons.
Then these uncaught exceptions started to appear on REAL released versions
randomly.
(The exceptions are from the error console of TB 38.5.1 under linux, and
I am about to upgrade to 38.6)

My proposal and question:
Is there any chance that JS engine can be modified to print automatically
the traceback of the full stack all the way down to where the exception was
thrown, when the exception was not caught by catch at intermediate level of
the stack.

That is only when the JS interpreter figures out the exception is not caught
at all
and decedes to print uncaught exception: ddddddddd, can the interpreter
prints the stack backtrace fully?

It then means not clearing the stack immediately as it traverses to find the
matching catch. Only when it finds the catch or not find the catch and goes
up to top-level,
it unwinds the stack for real and do appropriate action (handing over
exception to the catch portion, or print the full stack before unwinding the
stack fully
for uncaught exception as I mention above)
Of course, the feature can be turned on/off by a global variable
configuration or something.

This should help debugging rarely found unexpected exceptions because such
unexpected errors tend to be not caught by existing "catch" and reproducing
the error and obtaining the stacktrace may not be easy due to intermittant
nature.
If the first occurence of such unexpected exception is accompanied by full
stack trace, debugging proceeds very efficiently, doesn't it?


Unless something like this is implemented, debugging this strange uncaught
exception will be extremely hard.

Short of someone stepping in to modify the interpreter, can someone suggest
which files are to modify and which functions to modify?
I think the modifications should be trivial (unless there are some special
cautions
while processing outlined above takes place. Like disabling signal, etc.,
watch out for memory exhaustion to record the possibly unbounded depth of
stack, etc.)
If nobody steps in, I may be even tempted to enter the fray because

I think these uncaught exceptions may be very bad for TB which I use for
business (sorting many messages with large attachements for editing purposes).


TIA

PS: I wish JS interpreter is as friendly as typical CommonLisp interpreter.
I mean it can be tweaked in many ways for debugging strange issues (not for
ordinary users, but for developers of special software packages, hooking
interpreter may be the only solution if you inherit a program written in 100
K lines of Lisp code :-)
I have not counted the lines in JS script source files in mozilla software, but
for limited man-power resources of thunderbird user community, it sure look
like 100K LOC :-)

BTW, Lisp has a full featured |boundp| operator to tell exactly whether the
symbol is bound to a valid value.
I wish JS has an equivalent. (Overloading nil, I mean null, and undefined for
failure expression is not a good coding practice. But I digress.)

_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Question about uncaught exceptions

Lars Hansen
​In CL boundp only works on the dynamic scope (ie globals); either of the
following functions seem to do the job for me, though the first one is
probably best because it can distinguish an undefined binding from one that
holds the value undefined.  Would be curious to know if that's not enough.

function boundp_1(n) {
  try { eval(String(n)); } catch (e) { return false; }
  return true;
}

var boundp_2 =
  (function (global) {
    return function(n) {
      return global[n] !== undefined;
    }
  })(this);


On Thu, Feb 18, 2016 at 7:22 AM, ishikawa <[hidden email]> wrote:

> Hi,
>
> Thunderbird occasionally sees these mysterious exceptions
> which are logged in its error console.
>
> uncaught exception: 2147500037
> uncaught exception: 2153578497
>
> At least these are also generated
> during |make mozmill| test suite run of C-C TB sometimes (not always, I
> think).
>
> However, analyzing these uncaught exceptions has been very difficult and
> has
> been put on back burner for more than two years for obvious reasons.
> Then these uncaught exceptions started to appear on REAL released versions
> randomly.
> (The exceptions are from the error console of TB 38.5.1 under linux, and
> I am about to upgrade to 38.6)
>
> My proposal and question:
> Is there any chance that JS engine can be modified to print automatically
> the traceback of the full stack all the way down to where the exception was
> thrown, when the exception was not caught by catch at intermediate level of
> the stack.
>
> That is only when the JS interpreter figures out the exception is not
> caught
> at all
> and decedes to print uncaught exception: ddddddddd, can the interpreter
> prints the stack backtrace fully?
>
> It then means not clearing the stack immediately as it traverses to find
> the
> matching catch. Only when it finds the catch or not find the catch and goes
> up to top-level,
> it unwinds the stack for real and do appropriate action (handing over
> exception to the catch portion, or print the full stack before unwinding
> the
> stack fully
> for uncaught exception as I mention above)
> Of course, the feature can be turned on/off by a global variable
> configuration or something.
>
> This should help debugging rarely found unexpected exceptions because such
> unexpected errors tend to be not caught by existing "catch" and reproducing
> the error and obtaining the stacktrace may not be easy due to intermittant
> nature.
> If the first occurence of such unexpected exception is accompanied by full
> stack trace, debugging proceeds very efficiently, doesn't it?
>
>
> Unless something like this is implemented, debugging this strange uncaught
> exception will be extremely hard.
>
> Short of someone stepping in to modify the interpreter, can someone suggest
> which files are to modify and which functions to modify?
> I think the modifications should be trivial (unless there are some special
> cautions
> while processing outlined above takes place. Like disabling signal, etc.,
> watch out for memory exhaustion to record the possibly unbounded depth of
> stack, etc.)
> If nobody steps in, I may be even tempted to enter the fray because
>
> I think these uncaught exceptions may be very bad for TB which I use for
> business (sorting many messages with large attachements for editing
> purposes).
>
>
> TIA
>
> PS: I wish JS interpreter is as friendly as typical CommonLisp interpreter.
> I mean it can be tweaked in many ways for debugging strange issues (not for
> ordinary users, but for developers of special software packages, hooking
> interpreter may be the only solution if you inherit a program written in
> 100
> K lines of Lisp code :-)
> I have not counted the lines in JS script source files in mozilla
> software, but
> for limited man-power resources of thunderbird user community, it sure look
> like 100K LOC :-)
>
> BTW, Lisp has a full featured |boundp| operator to tell exactly whether the
> symbol is bound to a valid value.
> I wish JS has an equivalent. (Overloading nil, I mean null, and undefined
> for
> failure expression is not a good coding practice. But I digress.)
>
> _______________________________________________
> dev-tech-js-engine mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Question about uncaught exceptions

ISHIKAWA,chiaki
In reply to this post by ISHIKAWA,chiaki
On 2016年02月18日 16:15, Lars Hansen wrote:

> ​In CL boundp only works on the dynamic scope (ie globals); either of the
> following functions seem to do the job for me, though the first one is
> probably best because it can distinguish an undefined binding from one that
> holds the value undefined.  Would be curious to know if that's not enough.
>
> function boundp_1(n) {
>   try { eval(String(n)); } catch (e) { return false; }
>   return true;
> }
>
> var boundp_2 =
>   (function (global) {
>     return function(n) {
>       return global[n] !== undefined;
>     }
>   })(this);
>

This is interesting, especially |String(n)| usage.
I didn't realize it was possible.
>  because it can distinguish an undefined binding from one that
>  holds the value undefined.

This may be useful for me in the future.
There have been cases when JS reported something as |undefined| but
the subsequent debugging could not determine the true nature of the issues.
But it was a couple of years ago, and
so I forgot the details. Strict mode tended to pick up
strange situations which were difficult to analyze back then.


Any thoughts about the automatic dump of stack
when uncaught exception is thrown all the way to the top-level ?

TIA


>
> On Thu, Feb 18, 2016 at 7:22 AM, ishikawa <[hidden email]> wrote:
>
>> Hi,
>>
>> Thunderbird occasionally sees these mysterious exceptions
>> which are logged in its error console.
>>
>> uncaught exception: 2147500037
>> uncaught exception: 2153578497
>>
>> At least these are also generated
>> during |make mozmill| test suite run of C-C TB sometimes (not always, I
>> think).
>>
>> However, analyzing these uncaught exceptions has been very difficult and
>> has
>> been put on back burner for more than two years for obvious reasons.
>> Then these uncaught exceptions started to appear on REAL released versions
>> randomly.
>> (The exceptions are from the error console of TB 38.5.1 under linux, and
>> I am about to upgrade to 38.6)
>>
>> My proposal and question:
>> Is there any chance that JS engine can be modified to print automatically
>> the traceback of the full stack all the way down to where the exception was
>> thrown, when the exception was not caught by catch at intermediate level of
>> the stack.
>>
>> That is only when the JS interpreter figures out the exception is not
>> caught
>> at all
>> and decedes to print uncaught exception: ddddddddd, can the interpreter
>> prints the stack backtrace fully?
>>
>> It then means not clearing the stack immediately as it traverses to find
>> the
>> matching catch. Only when it finds the catch or not find the catch and goes
>> up to top-level,
>> it unwinds the stack for real and do appropriate action (handing over
>> exception to the catch portion, or print the full stack before unwinding
>> the
>> stack fully
>> for uncaught exception as I mention above)
>> Of course, the feature can be turned on/off by a global variable
>> configuration or something.
>>
>> This should help debugging rarely found unexpected exceptions because such
>> unexpected errors tend to be not caught by existing "catch" and reproducing
>> the error and obtaining the stacktrace may not be easy due to intermittant
>> nature.
>> If the first occurence of such unexpected exception is accompanied by full
>> stack trace, debugging proceeds very efficiently, doesn't it?
>>
>>
>> Unless something like this is implemented, debugging this strange uncaught
>> exception will be extremely hard.
>>
>> Short of someone stepping in to modify the interpreter, can someone suggest
>> which files are to modify and which functions to modify?
>> I think the modifications should be trivial (unless there are some special
>> cautions
>> while processing outlined above takes place. Like disabling signal, etc.,
>> watch out for memory exhaustion to record the possibly unbounded depth of
>> stack, etc.)
>> If nobody steps in, I may be even tempted to enter the fray because
>>
>> I think these uncaught exceptions may be very bad for TB which I use for
>> business (sorting many messages with large attachements for editing
>> purposes).
>>
>>
>> TIA
>>
>> PS: I wish JS interpreter is as friendly as typical CommonLisp interpreter.
>> I mean it can be tweaked in many ways for debugging strange issues (not for
>> ordinary users, but for developers of special software packages, hooking
>> interpreter may be the only solution if you inherit a program written in
>> 100
>> K lines of Lisp code :-)
>> I have not counted the lines in JS script source files in mozilla
>> software, but
>> for limited man-power resources of thunderbird user community, it sure look
>> like 100K LOC :-)
>>
>> BTW, Lisp has a full featured |boundp| operator to tell exactly whether the
>> symbol is bound to a valid value.
>> I wish JS has an equivalent. (Overloading nil, I mean null, and undefined
>> for
>> failure expression is not a good coding practice. But I digress.)
>>
>> _______________________________________________
>> dev-tech-js-engine mailing list
>> [hidden email]
>> https://lists.mozilla.org/listinfo/dev-tech-js-engine
>>
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Question about uncaught exceptions

Boris Zbarsky
In reply to this post by ISHIKAWA,chiaki
On 2/18/16 1:22 AM, ishikawa wrote:
> That is only when the JS interpreter figures out the exception is not caught
> at all
> and decedes to print uncaught exception: ddddddddd

The JS interpreter is not what decides to print that.  The DOM and
console code do that.  Those could show the stack if the exception had one.

Now right now the DOM code is buggy for XPConnect exceptions and doesn't
hand the stack over to the console.  Also, there are problems with the
console handling exceptions from non-window contexts.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=1208641 for details.

Once those are fixed, we may still have a problem if what's being thrown
here is not a DOMException, XPConnect Exception, or JS Error object,
since other exception values don't bring a stack along with them.
Keeping track of the stack independently of the exception value could be
a bit harder, because there's all sorts of internal code that
effectively catches and rethrows exceptions, so the stack would get
hopelessly confused.

> I think the modifications should be trivial

I don't think they are.

-Boris
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine
Reply | Threaded
Open this post in threaded view
|

Re: Question about uncaught exceptions

ISHIKAWA,chiaki
On 2016年02月19日 17:33, ishikawa wrote:

> On 2016年02月19日 12:34, Boris Zbarsky wrote:
>> On 2/18/16 10:08 PM, ishikawa wrote:
>>> SImply dumping what the JS interprer written in C++ knows to the STDERR
>>> is just fine to debug user-level uncaught exception.
>>
>> Ah, I had not gotten the impression that you could reproduce this
>> locally/reliably.
>>
> No, I cannot easily reproduce it under controlled condition.
> That makes debugging very tough.
>
>> You could certainly dump a stack whenever a pending exception is set, but
>> that would be pretty noisy.  You could try to do it when debugger would be
>> notified about exceptions if it were attached, and maybe crib something from
>> DebuggerScript_isInCatchScope to ignore things that are immediately caught...
>>
>> -Boris
>
> Still not easy, erh?
>
> But maybe I will look into DebuggerScript_isInCatchScope, etc. to
> see if it can get far.
>
> CI
>
Hi,

Maybe I am still too clueless.

I realized that

   DebuggerScript_isInCatchScope

is a function only linked and used by standalone (?) JS debugger.
(I realized this out when I try to print something from this
function.)

So the suggestion was to stop at a certain function where an exception
is thrown, and then figure out, from within the debugger, by calling
this function to see if the exception is caught in the scope of a chosen
function.  If not try finding the catch in another enclosing scope,
etc.  Ok, it is doable, once the originating position of the thrown
exception is known, I suppose.

What I wanted, though, to insert the main JS interpreter (linked into
TB?) a piece of code to print newly created exception so that just
before when "uncaught exception" is printed, an additional message is
printed from the JS intepreter itself.  This is because the uncaught
exceptions which I see are observed during batch-like exectution of
|make mozmill| and it leaves little room for human intervention such
as gdb interaction. My best bet to figure out what is causing the
original execution is to sprinkle the code with print/dump statement
to home in the cause.

Is it difficult to insert a code into JS interpreter to print something
every time an exception is raised?
(I understand that the output may be voluminous, but I can cope with it.)

Can the running code be already compbiled into bytecode or even
native code and is difficult to handle in this manner?

I suppose, though, for handling a complex event like raising an
exception, a C++ function is entered to handle such an operation with
the interpreter, right?  (Or maybe there is a very complex bytecode
instruction to handle the throwing of an exception.  In this case, I
simply need to insert a proble to that portion of the interpreter.)
I am clueless about this. Any guidance is appreciated.

So let me rephrase the original question. As a starter, I want to
print something from the JS interpreter or bytecode interpreter, etc.
(written in C++ ?)  when an exception is about to be thrown, any
exception at that.

By the way, "uncaught exception" is found as in the excerpt below from |make
mozmill| test suite run using DEBUG BUILD of C-C TB.

TEST-START |
/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mail/test/mozmill/composition/test-attachment.js
| test_open_attachment
++DOCSHELL 0x59b09a0 == 23 [pid = 8415] [id = 33]
++DOMWINDOW == 72 (0x1588720) [pid = 8415] [serial = 82] [outer = (nil)]
++DOMWINDOW == 73 (0x165d520) [pid = 8415] [serial = 83] [outer = 0x1588720]
++DOCSHELL 0x51518c0 == 24 [pid = 8415] [id = 34]
++DOMWINDOW == 74 (0x4c76110) [pid = 8415] [serial = 84] [outer = (nil)]
++DOCSHELL 0x22e7b60 == 25 [pid = 8415] [id = 35]
++DOMWINDOW == 75 (0x399df50) [pid = 8415] [serial = 85] [outer = (nil)]
++DOCSHELL 0x137d2a0 == 26 [pid = 8415] [id = 36]
++DOMWINDOW == 76 (0x4b332a0) [pid = 8415] [serial = 86] [outer = (nil)]
++DOMWINDOW == 77 (0x165cf20) [pid = 8415] [serial = 87] [outer = 0x399df50]
++DOMWINDOW == 78 (0x166abf0) [pid = 8415] [serial = 88] [outer = 0x4c76110]
++DOMWINDOW == 79 (0x1672220) [pid = 8415] [serial = 89] [outer = 0x399df50]
++DOMWINDOW == 80 (0x15f3bc0) [pid = 8415] [serial = 90] [outer = 0x4b332a0]
++DOMWINDOW == 81 (0x22989d0) [pid = 8415] [serial = 91] [outer = 0x399df50]
[8415] WARNING: NS_ENSURE_TRUE(sheet) failed: file
/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/editor/libeditor/nsHTMLEditor.cpp,
line 2920
[8415] WARNING: NS_ENSURE_TRUE(aNode) failed: file
/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/editor/libeditor/nsEditor.cpp,
line 3364
[8415] WARNING: NS_ENSURE_TRUE(name) failed: file
/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/dom/base/nsDOMAttributeMap.cpp,
line 386
JavaScript error: resource://mozmill/modules/utils.js, line 478: uncaught
exception: 2153578497
[8415] WARNING: NS_ENSURE_TRUE(window) failed: file
/new-hd1/extra/ishikawa/TB-3HG/NEW-COMMSRC/mozilla/uriloader/exthandler/nsExternalHelperAppService.cpp,
line 2560
++DOCSHELL 0x4981640 == 27 [pid = 8415] [id = 37]

I finally figured out this particular one probably comes from
mail/test/resources/mozmill/mozmill/extension/resource/modules/utils.js
This file must be combined and preprocessed (?) with other utils.js to
produce the resource://mozmill/modules/utils.js.)
The modules/utils.js in object directory gets overwritten each time I build TB
so I may be missing something here.  I better be careful so that my mods
don't get lost.
(there is another different exception, but let me tackle that later).

One of the following statements in the file
        thread.processNextEvent(true);
is throwing exception, it seems.

Putting the above statement inside try {} catch(e) { dump ("exception " + e
+ "\n"); }
produces an interesting behavior.

Something is wrong.
After I edited the file and inserted dump statements, and inserted
whitespace lines to
change the line numbers to make sure I am looking at the correct file and
the line
numbers printed by the "uncaught exception" message changes with my editing,
I got stuck
with a very strange buggy symptom.

Here is the error from the test log now:

JavaScript error: resource://mozmill/modules/utils.js, line 407: uncaught
exception: 2153578497

~/objdir-tb3 is my MOZ_OBJ directory and the exception occurs in this file.
(Like I said,
I changed the line numbers by inserting space only lines and I get the
changed line
in the error message, at each edit. so I am sure this is the file.)

~/objdir-tb3/_tests/mozmill/resources/mozmill/mozmill/extension/resource/modules/utils.js

Why do I still get "uncaught exception" on line 407.
It is INSIDE a try {}, and I am trying to catch an exception as far as I can
tell.

Let me check.

  399  var thread = Components.classes["@mozilla.org/thread-manager;1"].
  400               getService().currentThread;
  401  while(!timeup) {
  402
  403      // dump("Looping in a while loop in utils.js at L402\n");
  404
  405      try {
  406
  407          thread.processNextEvent(true);
  408
  409      } catch (e) {
  410
  411          dump("Exception at L406.\n");
  412          // dump ("exception in sleep?: " + e + "\n");
  413      }
  414  }
  415 }



But I am not a everyday JS programmer (I use C, Lisp, etc. mainly.)
So maybe I am missing something here again.
Is there a bytecode cache or something I should clear after runninng build
command?

Or is there a known bug in JS that does not catch exception as expected? :
hard to believe, but after seeing the above, I am ready to believe it.

Hmm...

Debugging JS code during BATCH-like execution of C-C TB |make mozmill| test
suite is tough.

TIA
_______________________________________________
dev-tech-js-engine mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-tech-js-engine