Capturing the JS stack in case of crash

2014-07-08 Thread David Rajchenbach-Teller
Often, we find ourselves attempting to debug JS code that causes a
crash, generally by miscalling a XPCOM component that causes an
assertion failure. Unfortunately, in such cases, the native stack
captured gives little to no indication that can help developers find out
how we reached this specific assertion. This is true both when we run
code locally, on Try or when Firefox is released to users.

Could we find a way to capture the JS stack?

I have the impression that it would be sufficient to modify our
assertion macros to call a DumpJSStack() equivalent before actually
crashing, and to attach the output to the Crash Reporter if available.

Cheers,
 David

-- 
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform


Re: Capturing the JS stack in case of crash

2014-07-08 Thread Benjamin Smedberg


On 7/8/2014 9:25 AM, David Rajchenbach-Teller wrote:

Often, we find ourselves attempting to debug JS code that causes a
crash, generally by miscalling a XPCOM component that causes an
assertion failure. Unfortunately, in such cases, the native stack
captured gives little to no indication that can help developers find out
how we reached this specific assertion. This is true both when we run
code locally, on Try or when Firefox is released to users.

Could we find a way to capture the JS stack?

I have the impression that it would be sufficient to modify our
assertion macros to call a DumpJSStack() equivalent before actually
crashing, and to attach the output to the Crash Reporter if available.


We've wanted something like this for a long time, but it's really hard 
to get right in the general case. The hazards involved include:


* asserts sometimes happen within mutexes which could mean deadlock hazards
* Depending on the situation, we might not even have the JS engine 
initialized yet
* Does the JS stackwalker ever trigger GC or other callbacks into gecko? 
We really can't stand re-entrancy in this case. Does it matter if the JS 
code in question is currently in a JIT frame versus an interpreted frame?
* Since asserts are usually signs of broken code to begin with, we need 
to be very defensive both in terms of security and additional crash 
protection.


In the naive case of somebody who is currently using nsIDebug.abort from 
JS code, I suspect most of these objections don't apply, and we could do 
this fairly safely. But I'm not so sure it's something we should do in 
the general case.


The other thing to consider is whether we can change the JS engine so 
that the stack can be reconstructed from information in the minidump 
itself. Especially if we can localize the stack data into a small number 
of pages/pseudostack, that might be a better way to approach the problem 
here. But it's also likely to be a big engineering effort.


--BDS

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform