533035 - Extensions/libraries/plugins might enable FPU/SSE2 exceptions, causing floating-point operations to crash. fixes for crashes [@ isPromoteInt ] [@ _ftol2 ] [@ JS_dtobasestr] and others

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P2)

Description

[chris hofmann]

caught this on the new ranking report as one of the signatures not on file and one that is on the rise.  currently ranked #35 for 3.6b4

http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.6b4/3

stack traces look like

Frame  	Module  	Signature [Expand]  	Source
0 	kernel32.dll 	RaiseException 	
1 	mozcrt19.dll 	_raise_exc_ex 	
2 	mozcrt19.dll 	_raise_exc 	
3 	mozcrt19.dll 	_87except 	
4 	mozcrt19.dll 	_startOneArgErrorHandling 	
5 	mozcrt19.dll 	_CIlog_default 	
6 	mozcrt19.dll 	_CIlog_default 	
7 	js3250.dll 	math_log 	js/src/jsmath.cpp:334
8 	js3250.dll 	js_Interpret 	js/src/jsops.cpp:220

more reports at

http://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=_raise_exc_ex&version=Firefox%3A3.6b4

source at the top of the stack has been changing during the last few months of 3.6 development

http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/4c488520d1bf/js/src/jsmath.cpp#l334

a few comments in languages I don't understand, and one in portuguese that indicates it might be a repeated crash for the user.

Comment 1

[chris hofmann]

volume on the beta looks higher than previous releases

checking --- 20091203-crashdata.csv _raise_exc_ex
release total-crashes
              _raise_exc_ex crashes
                         pct.
all     227654  127     0.000557864
3.0.15  46823   8       0.000170856
3.5.5   120949  34      0.00028111
3.6b4   18432   49      0.00265842
3.6b3   1579    6       0.00379987
3.6b2   1255    8       0.0063745
3.6b1   2924    11      0.00376197

os breakdown
54      0.425197        Windows NT5.1.2600 Service Pack 3
48      0.377953        Windows NT5.1.2600 Service Pack 2
10      0.0787402       Windows NT6.0.6001 Service Pack 1
7       0.0551181       Windows NT6.1.7600
3       0.023622        Windows NT6.0.6002 Service Pack 2
3       0.023622        Windows NT6.0.6000
1       0.00787402      Windows NT5.1.2600 Service Pack 1
1       0.00787402      Windows NT5.1.2600 Dodatek Service Pack 2


a very high number of the crashes appear to come from this site

http://odnoklassniki.ru/

with the urls looking something like

http://wg155.odnoklassniki.ru/dk;jsessionid= ---sanitize session id info

Comment 2

[David Mandelin [:dmandelin]]

The crashes appear to be a divide-by-zero/invalid-fp-op on the line that calls log. (I didn't dig into minidumps to prove this, though). All the changes seem pretty ancient (pre-2009) so it's hard to see how this could be a new bug. 

    1.87  #endif
    1.88 -    z = fd_log(x);
    1.89 +    z = log(x);
    1.90      return js_NewNumberInRootedValue(cx, z, vp);
    1.91  }
    1.92

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Any DLL correlation?  Could be something jerking around the FPU control word on us again...

Comment 4

[Andreas Gal :gal]

We might be able to reproduce this through fuzzing different values into log?

Comment 5

[Andreas Gal :gal]

     log(+-0) , log2(+-0) , and log10(+-0) return -infinity and raise the "divide-by-zero" floating-point exception.

     log(x) , log2(x) , and log10(x) return a NaN and raise the "invalid" floating-point exception for x < 0.

#if defined(SOLARIS) && defined(__GNUC__)
    if (x < 0) {
        *vp = cx->runtime->NaNValue;
        return JS_TRUE;
    }
#endif
    z = log(x);
    return js_NewNumberInRootedValue(cx, z, vp);

Looks like a bug alright.

Comment 6

[chris hofmann]

Attachment: crash counts for _raise_exc_ex 4oct-3dec

yeah, there might be some historical bug that was causing about 20-40 crashes per day, then we appear to start ramping up around the release of 3.6b1.  now we are running 120-180 crashes per day on this signature.  I guess we need to dig deeper to see if there are multiple bugs here with the same signature.

Comment 7

[Andreas Gal :gal]

Chris, can you help me getting a small piece of code to run on the same OS / compiler than the reported crashes?

Comment 8

[chris hofmann]

the stacks with crash addresses 0x75309617 have a bit different stack

http://crash-stats.mozilla.com/report/index/fcd774bb-2041-467f-9a9e-11dbc2091128

Comment 9

[Andreas Gal :gal]

Yeah same issue there, slightly different stack. We fail to exclude x < 0 for sqrt.

     sqrt(x) returns a NaN and generates a domain error for x < 0.

Comment 10

[Andreas Gal :gal]

I would like to confirm that win32 with msvc8 actually raises an exception. macosx doesn't (despite the manual telling the world it would).

Comment 11

[chris hofmann]

I have a vista vm running on my macbook that might match one of the os'es listed above.   ctalbert might have a wider array of vm's that will match the winXP versions at the top of the list.  If you put your program somewhere I'll give it a try.  if it's small enough it might just attach to the bug.

Comment 12

[David Mandelin [:dmandelin]]

I just tried log(-1) with MSVC8 on Vista and it seems to compute the answer as NaN (it prints |-1.#IND00|, the same as it prints for |double(0)/0|.). Anyway, it doesn't fault.

I'm thinking FPU control word.

Comment 13

[Andreas Gal :gal]

So libc says its ok to raise an exception there and we don't check and exclude those value ranges. I think its prudent to just go ahead and patch this. chris, can you check whether you can find any other related stacks? I will patch sqrt and log. Anything else?

Comment 14

[chris hofmann]

in this batch I notice crash reason marked as

_raise_exc_ex|EXCEPTION_FLT_INVALID_OPERATION

and 

_raise_exc_ex|EXCEPTION_FLT_DIVIDE_BY_ZERO 

I'll go look for other possibilities

Comment 15

[chris hofmann]

I'm grinding though all the recent crash reports for _raise_exc_ex looking at the top line of the stack.

so far lots of 
http://hg.mozilla.org/releases/mozilla-1.9.1/annotate/57f71400f4cf/js/src/jsmath.cpp#l334   -- log

and 

http://hg.mozilla.org/releases/mozilla-1.9.2/annotate/c60105da01a0/js/src/jsmath.cpp#l530  -- sqrt

but 

http://hg.mozilla.org/releases/mozilla-1.9.1/annotate/57f71400f4cf/js/src/jsmath.cpp#l426  also just showed up.

I'll let this script run for a few more hours and we should have a comprehensive list.

Comment 16

[chris hofmann]

couple reports of 

http://hg.mozilla.org/releases/mozilla-1.9.1/annotate/57f71400f4cf/js/src/jsmath.cpp#l325   just a bit earlier within math_log

and looks like the line numbers are a bit different on the trunk 

http://hg.mozilla.org/mozilla-central/annotate/e48f74a76449/js/src/jsmath.cpp#l528 

maybe due to landing of changes for bug 524346 
http://hg.mozilla.org/mozilla-central/log/f2aa13fe2077/js/src/jsmath.cpp

that covers all the _raise_exc_ex signatures in crash reports for the first 3 days of Dec.

Comment 17

[chris hofmann]

search on the 2500 reports for Nov. crashes should be done by the morning.

Comment 18

[chris hofmann]

in the scanning off all Nov. reports these new lines showed up

http://hg.mozilla.org/mozilla-central/annotate/74e3158a9fc5/js/src/jsmath.cpp#l627
http://hg.mozilla.org/mozilla-central/annotate/77136b3d68fc/js/src/jsmath.cpp#l627
  --variation of log?

http://hg.mozilla.org/releases/mozilla-1.9.1/annotate/49342a1d9d93/js/src/jsmath.cpp#l573  variation of sqrt?

If that is right and they are covered by the log and sqrt patches, then the only other possible patch to look at might be for math_pow 
http://hg.mozilla.org/releases/mozilla-1.9.1/annotate/57f71400f4cf/js/src/jsmath.cpp#l426

Comment 19

[Jim Blandy :jimb]

(In reply to comment #6)
> Created an attachment (id=416216) [details]
> crash counts for _raise_exc_ex  4oct-3dec 
> 
> yeah, there might be some historical bug that was causing about 20-40 crashes
> per day, then we appear to start ramping up around the release of 3.6b1.  now
> we are running 120-180 crashes per day on this signature.  I guess we need to
> dig deeper to see if there are multiple bugs here with the same signature.

Well, it could also be certain sites growing in popularity.

Comment 20

[chris hofmann]

here is an example crash report for the math_pow case
http://crash-stats.mozilla.com/report/index/86130241-38f3-4c6a-915e-073792091201

there were very few of these for all of Nov./Dec.

Comment 21

[chris hofmann]

(In reply to comment #19)
> (In reply to comment #6)
> > Created an attachment (id=416216) [details] [details]
> > crash counts for _raise_exc_ex  4oct-3dec 
> > 
> > yeah, there might be some historical bug that was causing about 20-40 crashes
> > per day, then we appear to start ramping up around the release of 3.6b1.  now
> > we are running 120-180 crashes per day on this signature.  I guess we need to
> > dig deeper to see if there are multiple bugs here with the same signature.
> 
> Well, it could also be certain sites growing in popularity.

Thinking about this some more, its possible that adjustments to the skip list might be playing a role in the visibility of this too.  

IIRC, I think we might have made adjustments to skip  kernel32.dll RaiseException

and maybe that's allowing "_raise_exc_ex"  to surface in new patterns that were not visible before when all these were lumped under "RaiseException"

Comment 22

[chris hofmann]

looks like jimb is right.

The most popular sites for this crash in the last few days are

http://www.orkut.com.br/ and http://www.orkut.co.in/

Looks like the increase might be tied to the new release of orkut.  

http://en.blog.orkut.com/2009/10/introducing-new-version-of-orkut-fun.html
maybe this is tied to something in the Google Web Toolkit

here are crash counts by day of users that reported a _raise_exc_ex while visiting orkut

20091101-crashdata.csv 
20091102-crashdata.csv 
20091103-crashdata.csv 
20091104-crashdata.csv 1
20091105-crashdata.csv 
20091106-crashdata.csv 3
20091107-crashdata.csv 11
20091108-crashdata.csv 9
20091109-crashdata.csv 13
20091110-crashdata.csv 8
20091111-crashdata.csv 9
20091112-crashdata.csv 5
20091113-crashdata.csv 14
20091114-crashdata.csv 10
20091115-crashdata.csv 10
20091116-crashdata.csv 5
20091117-crashdata.csv 19
20091118-crashdata.csv 29
20091119-crashdata.csv 17
20091120-crashdata.csv 15
20091121-crashdata.csv 23
20091122-crashdata.csv 17
20091123-crashdata.csv 47
20091124-crashdata.csv 25
20091125-crashdata.csv 29
20091126-crashdata.csv 35
20091127-crashdata.csv 48
20091128-crashdata.csv 33
20091129-crashdata.csv 56
20091130-crashdata.csv 38
20091201-crashdata.csv 48
20091202-crashdata.csv 33
20091203-crashdata.csv 35

Comment 23

[chris hofmann]

Attachment: crash counts for all _raise_exc_ex and orkut _raise_exc_ex 4oct-3dec

or to show graphically....    orkut looks to be assoicated a pretty big chunk of the increase in these crashes

Comment 24

[chris hofmann]

there are also smaller numbers of reports with 
https://wave.google.com/wave and http://talkgadget.google.com/talkgadget as the crashing url so finding the set of apps using Google Web Toolkit might be worthwhile if the approach would be to try and fix on the content side.

Comment 25

[chris hofmann]

the number of uniq sites in the url list also seems to be increasing.

back on nov 2 there were about 13 non-odnoklassniki.ru and non-orkut urls.

on dec 2 that had increased to 56 non-odnoklassniki.ru and non-orkut urls.

something in embedded across sites like google analytics might be another area of content to check.

Comment 26

[chris hofmann]

looking at a quick sample of other pages that were reported with the crash, on common theme in each of these is that they all have google adsense.

http://www.montada.com/showthread.php?p=3268070
http://www.holidaytruths.co.uk/viewtopic.php?f=8&t=139915&p=1405667
http://www.russhare.ucoz.ru/load/24-1-0-673

Comment 27

[Andreas Gal :gal]

I am working on a patch for this. I don't think a windows libc in default settings raises this exception. This is very like an extension enable fp exceptions.

Comment 28

[Andreas Gal :gal]

Ok, so after some digging and thinking about it, I think the right way to fix this is:

- install an fp exception handler
- disable fp exceptions in the handler

As long we have binary extensions, they can always enable fp exceptions on us and make us crashy. We shouldn't take a slowdown in the generic code path because some extension, but we should also not risk being crashy because of them (in the spirit of crash-kill).

Opinions?

Comment 29

[Andreas Gal :gal]

Attachment: patch

This rather horrible and gross hack should catch and disable fp exceptions. Compiles on macosx. Didn't try linux or windows and I can't reproduce the crash (yet), but I try that next. If someone can reproduce and wants to give this a shot, go for it. Note: I don't think this belongs into the JS engine. This should go elsewhere in the platform. I will hang on to the bug, and move it to a different component.

Comment 30

[Andreas Gal :gal]

Plugins seems to be the right place for this. We compile our code to not muck with this, so this code is only necessary because plugins do naughty stuff to our FP environment. The code should be located somewhere in there, and can be removed as soon plugins go out of process. Not sure who is in charge of that domain over there, maybe I could have someone buddy up with me to figure out where to drop in the code.

Comment 31

[timeless]

no. we have lots of evil modules which are not plugins. generally speaking plugins are *relatively* well behaved.

Comment 32

[Andreas Gal :gal]

Well, anything that gets loaded into the system is potentially a problem. This has to be fixed someone in the startup path. plugins seems to be a reasonable place, but timeless is right, library code could also muck with this (shaver told me DirectX sometimes does). I am open to component suggestions, but this is definitely not JS.

Comment 33

[timeless]

http://msdn.microsoft.com/en-us/library/te2k2f2t.aspx

roughly ms wants us to use SEH :)

i think startup is now somewhere in toolkit/apprunner or something.

Comment 34

[David Mandelin [:dmandelin]]

There's a mystery "add-on" that seems to be associated with these:

http://www.raymond.cc/blog/archives/2008/06/27/my-temporary-solution-to-fix-mozilla-firefox-3-random-crashing-problem/

(See Update: I noticed...)

Comment 35

[David Mandelin [:dmandelin]]

Scratch that last comment; I think that's just some skin extension that comes with FF.

These _raise_exc_ex crashes seem closely related to the current top js_Interpret crashes on 3.6b4 and 3.7a1, which are invalid operation x87 FPU exceptions (#IA). That exception should be masked out, and is in default FF, but extensions are probably turning it on for some reason. See:

https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6b4&query_search=signature&query_type=startswith&query=js_Interpret%3A&date=&range_value=2&range_unit=weeks&do_query=1&signature=js_Interpret%3A916&page=1

Comment 36

[Andreas Gal :gal]

Attachment: patch

Comment 37

[David Mandelin [:dmandelin]]

Attachment: Example of handling x87 FPEs

This shows how to handle the x87 exceptions in VS8. The program crashes if the signal() call is removed.

Comment 38

[Andreas Gal :gal]

Attachment: code for macosx that shows how to supress FPU exceptions

The attached patch installs a signal handler for FPU exceptions for FPU and SSE and clears and disables exceptions whenever the handler is hit.

Use CFLAGS="-32 -mfpmath=sse" to test the SSE path, and -mfpmath=387 to test the FPU path.

This has to be ported to linux and win32, and should be ifdef 386.

Comment 39

[Mike Beltzner [:beltzner, not reading bugmail]]

Sayrer: can you help me understand if we should block Firefox 3.6 final release on this? New crash on the rise, fix in hand, feels like we probably should, but want to get your take on how far out this is and whether we need to do it before a 3.6.x. I can't tell how common the circumstances leading to it might be.

Comment 40

[chris hofmann]

while the crashes for 3.0.15 and 3.5.5 are pretty stable, the crashes against the 3.6b4 continue to rise in both real and pct. terms.  here is an update to the stats from comment 1


checking --- 20091213-crashdata.csv _raise_exc_ex
release total-crashes
              _raise_exc_ex crashes
                         pct.
all     224211  162     0.000722534
3.0.15  41285   12      0.000290662
3.5.5   125906  37      0.00029387
3.6b4   21461   89      0.00414706
3.6b3   808     3       0.00371287
3.6b2   883     1       0.0011325
3.6b1   2318    11      0.00474547

its hard to explain why this bug might affect 3.6 beta users more than it does previous releases, but some how it seems be.

Comment 41

[Andreas Gal :gal]

Attachment: patch

Comment 42

[Andreas Gal :gal]

Attached is a patch that seems to work on linux. Its not entirely clear to me how linux deals with this. It has two integer words for cw and sw and no access to the SSE2 register (mxcsr) in 32-bit mode. It seems the signal handler translates that internally.

In 64-bit mode we twiddle with the SSE2 control register and ignore the FPU register since all math is done with the SSE2 unit. Patch is untested as written, but I tested with a linux test application (attaching).

Comment 43

[Andreas Gal :gal]

Attachment: linux test code

Comment 44

[Andreas Gal :gal]

Attachment: patch

balance #ifdefs

Comment 45

[Andreas Gal :gal]

Attachment: added untested windows code

Comment 46

[Andreas Gal :gal]

Attachment: patch

fixed a typo in the linux handler, sent off to try server again

Comment 47

[Rob Arnold [:robarnold]]

Comment on attachment 417859 [details] [diff] [review]
patch

>-ifneq (,$(filter-out OS2 WINNT,$(OS_ARCH)))
>-CPPSRCS	  += nsSigHandlers.cpp
>-endif
>-

Since you're removing the OS/2 exclusion, you should CC the OS/2 developers so that they know you might be breaking their code. I don't know how their compiler handles this.
>+#if defined(__i386__)
>+  /*
>+   * It seems that we have no access to mxcsr on Linux. libc
>+   * seems to be translating cw/sw to mxcsr.
>+   */
>+  unsigned long int *cw = &uc->uc_mcontext.fpregs->cw;
>+  *cw |= 0x7f;
These numerical constants are scary. Can you use or #define something here to explain what you're doing?

>+#ifdef _M_IX86
>+typedef struct DECLSPEC_ALIGN(16) _M128A {
>+  ULONGLONG Low;
>+  LONGLONG High;
>+} M128A, *PM128A;
>+
>+/*
>+ * The ExtendedRegisters field of the x86.32 CONTEXT structure uses this layout; however,
>+ * this structure is only made available from winnt.h on x86.64
>+ */

Why can we not use FLOATING_SAVE_AREA for x86? ControlWord and StatusWord are still fields and MxCsr is the first 4 bytes of the RegisterArea field of the struct. Since it's hidden behind a macro, this doesn't seem too difficult to do and it's less code than repeating this structure definition here (which we are trying to do less of whenever possible anyways, so I am sad to see this here).

>+typedef struct _XMM_SAVE_AREA32 {
>+  WORD ControlWord;        /* 000 */
>+  WORD StatusWord;         /* 002 */
>+  BYTE TagWord;            /* 004 */
>+  BYTE Reserved1;          /* 005 */
>+  WORD ErrorOpcode;        /* 006 */
>+  DWORD ErrorOffset;       /* 008 */
>+  WORD ErrorSelector;      /* 00c */
>+  WORD Reserved2;          /* 00e */
>+  DWORD DataOffset;        /* 010 */
>+  WORD DataSelector;       /* 014 */
>+  WORD Reserved3;          /* 016 */
>+  DWORD MxCsr;             /* 018 */
>+  DWORD MxCsr_Mask;        /* 01c */
>+  M128A FloatRegisters[8]; /* 020 */
>+  M128A XmmRegisters[16];  /* 0a0 */
>+  BYTE Reserved4[96];      /* 1a0 */
>+} XMM_SAVE_AREA32, *PXMM_SAVE_AREA32;
>+
>+#define X87CW(ctx) (ctx)->FloatSave.ControlWord
>+#define X87SW(ctx) (ctx)->FloatSave.StatusWord
>+#define MXCSR(ctx) ((XMM_SAVE_AREA32*)((ctx)->ExtendedRegisters))->MxCsr
>+#endif
>+
>+#ifdef _M_X64
>+#define X87CW(ctx) (ctx)->FloatSave.ControlWord
>+#define X87SW(ctx) (ctx)->FloatSave.StatusWord
>+#define MXCSR(ctx) (ctx)->MxCsr
>+#endif
>+
>+#if defined(_M_IA32) || define(_M_X64)
>+/*
>+ * SSE traps raise these exception codes, which are defined in internal NT headers
>+ * but not winbase.h
>+ */
>+#define STATUS_FLOAT_MULTIPLE_FAULTS 0xC00002B4
>+#define STATUS_FLOAT_MULTIPLE_TRAPS  0xC00002B5
>+
>+LONG __stdcall FpeHandler(PEXCEPTION_POINTERS pe)
>+{
>+  PEXCEPTION_RECORD e = (PEXCEPTION_RECORD)pe->ExceptionRecord;
>+  CONTEXT *c = (CONTEXT*)pe->ContextRecord;
>+
>+  switch (e->ExceptionCode) {
>+    case STATUS_FLOAT_DENORMAL_OPERAND:
>+    case STATUS_FLOAT_DIVIDE_BY_ZERO:
>+    case STATUS_FLOAT_INEXACT_RESULT:
>+    case STATUS_FLOAT_INVALID_OPERATION:
>+    case STATUS_FLOAT_OVERFLOW:
>+    case STATUS_FLOAT_STACK_CHECK:
>+    case STATUS_FLOAT_UNDERFLOW:
>+    case STATUS_FLOAT_MULTIPLE_FAULTS:
>+    case STATUS_FLOAT_MULTIPLE_TRAPS:
>+      X87CW(c) |= 0x7f;
>+      X87SW(c) = 0;
>+      MXCSR(c) &= ~0x3f;
>+      MXCSR(c) |= (0x3f << 7);

These magic numbers look just like the Linux ones but without the comments explaining the magic. Is there any way we can have some code sharing (even if only #defines)?

Comment 48

[Andreas Gal :gal]

Hey rob, thanks for the fly-by.

Comment 49

[Andreas Gal :gal]

FLOATING_SAVE_AREA is different. Compare the struct closely. It uses DWORDs for cw/sw. Everyone who does this kind of FPE handling seems to use this custom struct.

> These magic numbers look just like the Linux ones but without the comments
> explaining the magic. Is there any way we can have some code sharing (even if
> only #defines)?

Yeah will do.

Comment 50

[Rob Arnold [:robarnold]]

(In reply to comment #49)
> FLOATING_SAVE_AREA is different. Compare the struct closely. It uses DWORDs for
> cw/sw. Everyone who does this kind of FPE handling seems to use this custom
> struct.

Ok, I see now. The control and status words are actually 16 bits (WORD-sized) so the use of DWORDs seems odd. Perhaps the upper bits are unused/ignored? Anyways, your patch is already using FLOATING_SAVE_AREA for those.

It's the MXSCR register that is new to me since it's for SSE. I don't think Microsoft would have changed FLOATING_SAVE_AREA to expose it. The layout XMM_SAVE_AREA32 corresponds exactly to the layout assumed by fxsave/fxrestor for 32 bit platforms. Seems quite excessive to define the entire struct just for one field but I don't see an alternative.

Nit: for sanity, you might want to assert that the CONTEXT's ContextFlags reports that the floating point/extended area is filled in.

Comment 51

[Andreas Gal :gal]

Attachment: patch

Comment 52

[Andreas Gal :gal]

Attachment: patch

Comment 53

[Andreas Gal :gal]

Attachment: patch

Comment 55

[Andreas Gal :gal]

Asking for review from the module owners (bs or vlad, either or, or both, at your leisure), and rob is helping as secondary reviewer with the FPU/SSE/windows magic.

Comment 56

[Rob Arnold [:robarnold]]

Comment on attachment 418120 [details] [diff] [review]
patch

>+#include <windows.h>
>+
>+#ifdef _M_IX86
>+
>+#if WINVER < 0x0601

I think this should be
#if MOZ_WINSDK_TARGETVER < MOZ_NTDDI_WIN7
since it's only needed for the 2k3 and Vista SDKS, right?

>+/*
>+ * SSE traps raise these exception codes, which are defined in internal NT headers
>+ * but not winbase.h
>+ */
>+#define STATUS_FLOAT_MULTIPLE_FAULTS 0xC00002B4
>+#define STATUS_FLOAT_MULTIPLE_TRAPS  0xC00002B5

These are defined in WinNT.h however so I'm curious why you aren't seeing them
or getting preprocessor collisions.

>+ * The Original Code is Mozilla Communicator client code.
Mozilla Communicator client?
>+ *
>+ * The Initial Developer of the Original Code is
>+ * Netscape Communications Corporation.
Original portion is Mozilla Corporation/Foundation code. I don't remember which
is the right one but Netscape is certainly wrong :)
>+ * Portions created by the Initial Developer are Copyright (C) 1998
Same w/the copyright date.

r+ with those changes and the winnt.h bits looked into. I see them defined in the 7 and Vista SDKs (I don't have the 2k3 one installed).

Comment 58

[Andreas Gal :gal]

Note that this patch doesn't fix problems related to changing the rounding mode by some rogue extension.

Comment 59

[Andreas Gal :gal]

I will try-land this on TM based on Rob's review since we have debug tinderboxes there that seem to suffer from this bug if I land my SSE double-to-int patch.

Comment 60

[Jesse Ruderman]

8 of the top 300 crashes in Firefox 3.6b4 are floating-point exceptions:

#29  (0.37%)  isPromoteInt
#37  (0.31%)  NormalizeColor            (see also bug 532141)
#50  (0.22%)  _ftol2                    (more than half, but not all)
#78  (0.17%)  js_Interpret:916
#141 (0.10%)  FuncFilter::ins2          (about half)
#158 (0.09%)  NPSWF32.dll@0xda96b
#253 (0.06%)  js_Interpret:904
#283 (0.05%)  js_Interpret:912

Comment 61

[Andreas Gal :gal]

Meh didn't see the nits. I will fix those.

Comment 62

[Andreas Gal :gal]

Landed on TM to cycle it. I will back it out in a bit.

http://hg.mozilla.org/tracemonkey/rev/17b58139d254

Comment 63

[Andreas Gal :gal]

(In reply to comment #56)
> (From update of attachment 418120 [details] [diff] [review])
> >+#include <windows.h>
> >+
> >+#ifdef _M_IX86
> >+
> >+#if WINVER < 0x0601
> 
> I think this should be
> #if MOZ_WINSDK_TARGETVER < MOZ_NTDDI_WIN7
> since it's only needed for the 2k3 and Vista SDKS, right?

Fixed. SDK7 has that, so thats where we want to turn it off.

> 
> >+/*
> >+ * SSE traps raise these exception codes, which are defined in internal NT headers
> >+ * but not winbase.h
> >+ */
> >+#define STATUS_FLOAT_MULTIPLE_FAULTS 0xC00002B4
> >+#define STATUS_FLOAT_MULTIPLE_TRAPS  0xC00002B5

We probably re-defined with the same value, which should be ok.

> 
> These are defined in WinNT.h however so I'm curious why you aren't seeing them
> or getting preprocessor collisions.
> 
> >+ * The Original Code is Mozilla Communicator client code.
> Mozilla Communicator client?
> >+ *
> >+ * The Initial Developer of the Original Code is
> >+ * Netscape Communications Corporation.
> Original portion is Mozilla Corporation/Foundation code. I don't remember which
> is the right one but Netscape is certainly wrong :)
> >+ * Portions created by the Initial Developer are Copyright (C) 1998
> Same w/the copyright date.

> 
> r+ with those changes and the winnt.h bits looked into. I see them defined in
> the 7 and Vista SDKs (I don't have the 2k3 one installed).

Comment 64

[Andreas Gal :gal]

Attachment: patch

with rob's nits

Comment 65

[Andreas Gal :gal]

Attachment: patch

Fresh license blurb.

Comment 66

[Benjamin Smedberg]

Comment on attachment 418120 [details] [diff] [review]
patch

>diff --git a/toolkit/xre/nsSigHandlers.cpp b/toolkit/xre/nsSigHandlers.cpp

>+#if !defined(XP_WIN) && !defined(XP_OS2)

I'd prefer this to be #ifdef XP_UNIX

>+#else

And then here, #elif defined(XP_UNIX), and at the end, an #else which either has a no-op implementation or an #error indicating that other platforms (OS/2, maybe symbian) will need an implementation.

>+#ifdef _M_IX86

This define covers both x86 and x86-64?

>+#if WINVER < 0x0601
>+typedef struct DECLSPEC_ALIGN(16) _M128A {
>+  ULONGLONG Low;
>+  LONGLONG High;
>+} M128A, *PM128A;
>+#endif

Where was this copied from? If from the MS SDK headers, I don't think we have legal rights to copy it here. We should just implement this if the SDK is new enough (and people with older SDKs have to do an explicit --with-windows-version=600 when they configure, so they've been forewarned).

Comment 67

[chris hofmann]

(In reply to comment #60)
> 8 of the top 300 crashes in Firefox 3.6b4 are floating-point exceptions:
> 
> #29  (0.37%)  isPromoteInt
> #37  (0.31%)  NormalizeColor            (see also bug 532141)
> #50  (0.22%)  _ftol2                    (more than half, but not all)
> #78  (0.17%)  js_Interpret:916
> #141 (0.10%)  FuncFilter::ins2          (about half)
> #158 (0.09%)  NPSWF32.dll@0xda96b
> #253 (0.06%)  js_Interpret:904
> #283 (0.05%)  js_Interpret:912


if we get all or most of these fixed with the work done here that would be the equivalent of fixing around the #5-#6 top crash bug.

Comment 68

[Andreas Gal :gal]

> 
> >+#ifdef _M_IX86
> 
> This define covers both x86 and x86-64?

This is 32-bit x86 only.

> 
> >+#if WINVER < 0x0601
> >+typedef struct DECLSPEC_ALIGN(16) _M128A {
> >+  ULONGLONG Low;
> >+  LONGLONG High;
> >+} M128A, *PM128A;
> >+#endif
> 
> Where was this copied from? If from the MS SDK headers, I don't think we have
> legal rights to copy it here. We should just implement this if the SDK is new
> enough (and people with older SDKs have to do an explicit
> --with-windows-version=600 when they configure, so they've been forewarned).

While I am most certainly not a layer, this is a functional definition of an interface. There is exactly one way to define this struct in C with proper names and proper types, hence this is not subject to copyright protection. We can drag in Harvey if we think we have to.

Comment 69

[Andreas Gal :gal]

The structure is described here btw:

http://msdn.microsoft.com/en-us/library/ms680617%28VS.85%29.aspx

Comment 70

[Andreas Gal :gal]

Attachment: patch

Comment 71

[Andreas Gal :gal]

Interdiff for bsmedberg

--- a/toolkit/xre/nsSigHandlers.cpp	
+++ a/toolkit/xre/nsSigHandlers.cpp	
@@ -44,7 +44,7 @@ 
 
 #include "nsSigHandlers.h"
 
-#if !defined(XP_WIN) && !defined(XP_OS2)
+#ifdef XP_UNIX
 
 #include <signal.h>
 #include <stdio.h>
@@ -345,7 +345,7 @@ 
 #endif
 }
 
-#else
+#elif XP_WIN
 
 #include <windows.h>
 
@@ -437,9 +437,12 @@ 
+
 #else
+
 void InstallSignalHandlers(const char *ProgramName)
 {
 }
-#endif
 
 #endif
 
-
+#else
+#error No signal handling implementation for this platform.
+#endif

Comment 72

[Benjamin Smedberg]

I unfortunately think we do need to drag legal in, based on prior experiences with almost the exact same situations.

Comment 73

[Andreas Gal :gal]

Attachment: patch

Comment 74

[Andreas Gal :gal]

Interdiff for bsmedberg

--- a/toolkit/xre/nsSigHandlers.cpp	
+++ a/toolkit/xre/nsSigHandlers.cpp	
@@ -351,13 +351,6 @@ 
 
 #ifdef _M_IX86
 
-#if MOZ_WINSDK_TARGETVER < MOZ_NTDDI_WIN7
-typedef struct DECLSPEC_ALIGN(16) _M128A {
-  ULONGLONG Low;
-  LONGLONG High;
-} M128A, *PM128A;
-#endif
-
 /*
  * The ExtendedRegisters field of the x86.32 CONTEXT structure uses this layout; however,
  * this structure is only made available from winnt.h on x86.64
@@ -376,9 +369,7 @@ 
   WORD Reserved3;          /* 016 */
   DWORD MxCsr;             /* 018 */
   DWORD MxCsr_Mask;        /* 01c */
-  M128A FloatRegisters[8]; /* 020 */
-  M128A XmmRegisters[16];  /* 0a0 */
-  BYTE Reserved4[96];      /* 1a0 */
+  /* Due to legal worries, this structure is intentionally incomplete after this point. */
 } XMM_SAVE_AREA32, *PXMM_SAVE_AREA32;
 
 #define MXCSR(ctx) ((XMM_SAVE_AREA32*)((ctx)->ExtendedRegisters))->MxCsr

Comment 75

[Andreas Gal :gal]

Comment on attachment 418242 [details] [diff] [review]
patch

How about this?

Comment 76

[Benjamin Smedberg]

Where did the declaration of _XMM_SAVE_AREA32 and MXCSR come from? I'm still signicantly worried about copying anything from MSDN.

Comment 77

[Andreas Gal :gal]

Attachment: patch

Comment 78

[Andreas Gal :gal]

Comment on attachment 418255 [details] [diff] [review]
patch

Removed the other structure as well.

Comment 79

[Andreas Gal :gal]

I really would like to get this is soon. Any other concerns?

Comment 80

[Benjamin Smedberg]

Comment on attachment 418255 [details] [diff] [review]
patch

Yeah, that works... although in some ways I'd be just as happy requiring the Win7 SDK.

Comment 81

[Andreas Gal :gal]

Its not really an SDK7 feature, MS just failed to move the structure into a public header, otherwise I would agree with depending on SDK7 as well.

Pushed to TM to cycle.

http://hg.mozilla.org/tracemonkey/rev/f3361958dcf7

Comment 82

[Jeff Walden [:Waldo]]

http://tinderbox.mozilla.org/showlog.cgi?log=TraceMonkey/1261160945.1261161803.11141.gz

You touched toolkit/xre/nsSigHandlers.cpp, could this be your bustage?

Comment 83

[Andreas Gal :gal]

bustage? the patch lives in nsSigHandlers

Comment 84

[Jeff Walden [:Waldo]]

I pushed http://hg.mozilla.org/tracemonkey/rev/4a6e89d95857 to fix bustage, in the seemingly obvious way -- looks like nobody ever tried to build the 64-bit parts during development.  Ex post facto reviews appreciated.

Comment 85

[Jeff Walden [:Waldo]]

..and http://hg.mozilla.org/tracemonkey/rev/8c3fa7078794 too.

Comment 86

[Andreas Gal :gal]

Thanks for spotting me waldo. r=me on the changes. I could have sworn I tried this on 64-bit linux. Maybe the API differs between distros or I accidentally built 32-bit linux.

Comment 87

[Robert Sayre]

http://hg.mozilla.org/mozilla-central/rev/f3361958dcf7

Comment 88

[Mike Beltzner [:beltzner, not reading bugmail]]

Do we still need that review from vlad, or should that be cleared?

Comment 89

[Jacek Caban]

Attachment: Compilation fix

This patch broken compilation on SVN GCC (mingw):

toolkit/xre/nsSigHandlers.cpp:364:31: error: missing binary operator before token "("

It's a simple typo s/define/defined/. The fix is attached.

Comment 90

[Andreas Gal :gal]

Fix by Jacek landed on TM:

http://hg.mozilla.org/tracemonkey/rev/a2213b12f253

Comment 91

[Jacek Caban]

Wrong but(In reply to comment #90)
> Fix by Jacek landed on TM:
> 
> http://hg.mozilla.org/tracemonkey/rev/a2213b12f253

It's about other bug and patch...

Comment 92

[Andreas Gal :gal]

Linking csets via iphone ..

http://hg.mozilla.org/tracemonkey/rev/15df947e8cdb

Comment 93

[Ginn Chen]

Attachment: fix for Solaris

Comment 94

[Ginn Chen]

I have 2 concerns of current solution:

1) "integer-divide-by-zero" would cause a hang rather than crash.

2) x86 32bit mode, on Solaris and maybe other platforms,
uc_mcontext.gregs[REG_PC] is not the instruction causing the floating-point FPE, it is the next instruction.
After executing "fpehandler", it will not redo the math with masks.
So the result may not be IEEE compliant.

Comment 95

[Andreas Gal :gal]

Why the crash?

Can we fix up pc on solaris?

Maybe solaris plugins are better behaved. I assume they are pretty rare anyway.

Comment 96

[Ginn Chen]

I've never this crash on Solaris.

I meant if we have a bug of Firefox or extension or plugin causing integer-divide-by-zero.
The SIGFPE handler will cause a hang.
Then we would not collect the data through crashreporter.

I think the solution would be comparing si->si_code with FPE_INTDIV, FPE_INTOVF, then raise SIGABRT.

For the x86 pc issue,
saved ip in fp_reg_set is the x87 FPU with exception.
greg[REG_PC] is the subsequent x87 FPU instruction where the error of previous x87 FPU instruction is detected.
We can fix up pc by assigning the saved ip in fp_reg_set to greg[REG_PC].
But if there're integer instructions between the 2 x87 FPU instructions, we may have problems.
I don't know if the compiler would generate code like that.

See "Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 1":
8.7.3	Handling x87 FPU Exceptions in Software

If the faulting floating-point instruction is followed by one or more non-floating-point instructions, it may not be useful to re-execute the faulting instruction. See Section 8.6, “x87 FPU Exception Synchronization,” for more information on synchronizing floating-point exceptions.

In cases where the handler needs to restart program execution with the faulting instruction, the IRET instruction cannot be used directly. The reason for this is that because the exception is not generated until the next floating-point or WAIT/FWAIT instruction following the faulting floating-point instruction, the return instruction pointer on the stack may not point to the faulting instruction. To restart program execution at the faulting instruction, the exception handler must obtain a pointer to the instruction from the saved x87 FPU state information, load it into the return instruction pointer location on the stack, and then execute the IRET instruction.

Comment 97

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: fix valgrind warning

While starting Firefox under valgrind, I saw the warning:

==30253== Syscall param rt_sigaction(act->sa_mask) points to uninitialised byte(s)
==30253==    at 0x4E392AE: __libc_sigaction (sigaction.c:67)
==30253==    by 0x5075D48: InstallSignalHandlers(char const*) (nsSigHandlers.cpp:307)
==30253==    by 0x5064C58: SetupErrorHandling(char const*) (nsAppRunner.cpp:3801)
==30253==    by 0x5069B8F: XRE_main (nsAppRunner.cpp:2739)
==30253==    by 0x40110C: main (nsBrowserApp.cpp:158)
==30253==  Address 0x7fefff058 is on thread 1's stack


According to man sigaction(2):
       sa_mask specifies a mask of signals  which  should  be  blocked  (i.e.,
       added  to  the signal mask of the thread in which the signal handler is
       invoked) during execution of the signal handler.  In addition, the sig‐
       nal  which triggered the handler will be blocked, unless the SA_NODEFER
       flag is used.

It doesn't seem particularly great to leave this uninitialized, although I'm not sure it's all *that* horrible.

Here's a patch to initialize to the empty set.

Comment 98

[Makoto Kato [:m_kato]]

Attachment: patch for Windows x64

no FloatSave member on x64 CONTEXT.

BTW, does _M_IA32 work on all version of MSVC? I believe that _M_IX86 is better than _M_IA32.

Comment 99

[Robert Sayre]

Still need to land the patches for Solaris, valgrind warning, and Windows x64

Comment 100

[Robert Sayre]

Attachment: build error on 192

this doesn't build on 1.9.2 OS X:

nsSigHandlers.cpp
c++ -o nsSigHandlers.o -c -I../../dist/system_wrappers -include /Users/sayrer/dev/192-branch/config/gcc_hidden.h -DIMPL_XREAPI -DMOZ_UPDATER -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES  -DZLIB_INTERNAL -DOSTYPE=\"Darwin9.8.0\" -DOSARCH=Darwin -DOS_TARGET=\"Darwin\" -DMOZ_WIDGET_TOOLKIT=\"cocoa\" -DTARGET_XPCOM_ABI=\"x86-gcc3\" -DTARGET_OS_ABI=\"Darwin_x86-gcc3\"  -DTOOLKIT_EM_VERSION=\"1.9.2b6pre\" -DWRAP_SYSTEM_INCLUDES -I/Users/sayrer/dev/192-branch/toolkit/xre -I/Users/sayrer/dev/192-branch/toolkit/xre/../profile/src -I/Users/sayrer/dev/192-branch/config  -I/Users/sayrer/dev/192-branch/toolkit/xre -I. -I../../dist/include -I../../dist/include/nsprpub  -I/Users/sayrer/dev/debug-192/dist/include/nspr -I/Users/sayrer/dev/debug-192/dist/include/nss      -I/usr/X11/include   -fPIC  -I/usr/X11/include -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -fno-strict-aliasing -fpascal-strings -fno-common -fshort-wchar -pthread -DNO_X11 -pipe -fexceptions  -DDEBUG -D_DEBUG -DDEBUG_sayrer -DTRACING -g -F/System/Library/PrivateFrameworks -DNO_X11   -I/usr/X11/include -DMOZILLA_CLIENT -include ../../mozilla-config.h -Wp,-MD,.deps/nsSigHandlers.pp /Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp: In function ‘void fpehandler(int, siginfo_t*, void*)’:
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:218: error: ‘struct mcontext32’ has no member named ‘__fs’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:219: error: ‘struct fp_control’ has no member named ‘__invalid’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:219: error: ‘struct fp_control’ has no member named ‘__denorm’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:219: error: ‘struct fp_control’ has no member named ‘__zdiv’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:219: error: ‘struct fp_control’ has no member named ‘__ovrfl’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:219: error: ‘struct fp_control’ has no member named ‘__undfl’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:219: error: ‘struct fp_control’ has no member named ‘__precis’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:221: error: ‘struct mcontext32’ has no member named ‘__fs’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:222: error: ‘struct fp_status’ has no member named ‘__invalid’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:222: error: ‘struct fp_status’ has no member named ‘__denorm’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:222: error: ‘struct fp_status’ has no member named ‘__zdiv’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:222: error: ‘struct fp_status’ has no member named ‘__ovrfl’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:222: error: ‘struct fp_status’ has no member named ‘__undfl’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:223: error: ‘struct fp_status’ has no member named ‘__precis’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:223: error: ‘struct fp_status’ has no member named ‘__stkflt’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:223: error: ‘struct fp_status’ has no member named ‘__errsumm’
/Users/sayrer/dev/192-branch/toolkit/xre/nsSigHandlers.cpp:225: error: ‘struct mcontext32’ has no member named ‘__fs’
make[1]: *** [nsSigHandlers.o] Error 1
make: *** [default] Error 2

Comment 101

[Ginn Chen]

Attachment: based on solaris patch address comment #94

You may want to add similar code for Mac, Linux, Windows.
Or just ignore the exception FPU instruction.

Without resetting uc->uc_mcontext.gregs[REG_PC],
0.0 * HUGE_VAL will return 0.0 if FPE is on, it will return NAN if FPE is off.
HUGE_VAL * 0.0 will return Inf is FPE is on, it will return NAN if FPE is off.

I don't like random math result.
So I want to fix it for Solaris.

Comment 102

[Robert Sayre]

Attachment: branch patch

this builds everywhere except OS X on the branch. same errors.

Comment 103

[Andreas Gal :gal]

sayrer, help needed?

Comment 104

[Andreas Gal :gal]

This looks like a macosx version issue. I was testing with snow leopard.

Comment 105

[Robert Sayre]

looks like an SDK version issue, because the mozilla-central builders are still using 10.5

Comment 106

[Robert Sayre]

*groan. This was really dumb. The 10.4 SDK has no underscores for the ucontext stuff. The only documentation of this turned out to be a post on the OpenMCL list by Gary Byers. Thank goodness for gb.

Comment 107

[Robert Sayre]

this is on the tryserver right now, will push after I get results.

Comment 108

[Robert Sayre]

this is now compiling with everything except gcc-4.0 + 10.4 SDK. gcc-4.2 + 10.4SDK works. working on it.

Comment 109

[Robert Sayre]

(In reply to comment #108)
> this is now compiling with everything except gcc-4.0 + 10.4 SDK. gcc-4.2 +
> 10.4SDK works. working on it.

OK, I think this is wrong. The other box seems to be using the 10.5 SDK. I put the OS X code in an #if 0 block. Seems to me that getting this out on Windows is the highest priority.

Comment 110

[Robert Sayre]

turned it off here:

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/481a4d546ab3

Comment 111

[Julian Seward [:jseward]]

Could someone please commit Dave Baron's patch in Comment #97 ?
Passing an uninitialised .sa_mask to the kernel is .. well, in
this case, as Dave says, probably harmless, but it's ungood and
adds unnecessarily to the Valgrind noise level.

Comment 112

[Benjamin Smedberg]

Comment on attachment 419148 [details] [diff] [review]
patch for Windows x64

How does this patch relate to bug 537489?

Comment 113

[Benjamin Smedberg]

In order to aid trunk and branch tracking, please file new bugs for the followup issues and request review there. This bug is long and confusing enough, and is status1.9.2 final-fixed.

Comment 114

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment 97 and comment 111 (fix valgrind warning) moved to bug 538013.

Comment 115

[Makoto Kato [:m_kato]]

(In reply to comment #112)
> (From update of attachment 419148 [details] [diff] [review])
> How does this patch relate to bug 537489?

No. x64 code is still broken after fixing bug 537489.  I will file a new bug for it, then send a review to you.

Comment 116

[David Mandelin [:dmandelin]]

Is this supposedly fixed on 1.9.2? Because I still see JS EXCEPTION_FLT_INVALID_OPERATION crashes coming in with the RC, e.g.:

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6&query_search=signature&query_type=startswith&query=js_Interpret&date=&range_value=1&range_unit=weeks&do_query=1&signature=js_Interpret%3A916

Comment 117

[David Mandelin [:dmandelin]]

(In reply to comment #116)
> Is this supposedly fixed on 1.9.2? Because I still see JS
> EXCEPTION_FLT_INVALID_OPERATION crashes coming in with the RC, e.g.:
> 
> http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6&query_search=signature&query_type=startswith&query=js_Interpret&date=&range_value=1&range_unit=weeks&do_query=1&signature=js_Interpret%3A916

See also

http://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6&query_search=signature&query_type=exact&query=_raise_exc_ex&date=&range_value=1&range_unit=weeks&do_query=1&signature=_raise_exc_ex

Comment 118

[Robert Sayre]

(In reply to comment #116)
> Is this supposedly fixed on 1.9.2? 

Bug 538642 is thwarting our efforts.

Comment 121

[Serge Gautherie (:sgautherie)]

Whiteboard says "[needs new 1.9.2 patch]",
Keywords has "checkin-needed":
please be more explicit about what you currently want!

Comment 122

[chris hofmann]

yeah,  a lot of frustrated firefox 3.6 users are still affected so we should figure out a plan for getting them the patches needed.

Comment 123

[Damon Sicore (:damons)]

(In reply to comment #121)
> Whiteboard says "[needs new 1.9.2 patch]",
> Keywords has "checkin-needed":
> please be more explicit about what you currently want!

This was fixed on 1.9.2, but the fix isn't being felt until we get bug 538642 on 1.9.2 as well. Updating whiteboard and keywords.

Comment 124

[Mark Banner (:standard8)]

This seems to be the bug for a top crash reported on Thunderbird (bug 540959 duped to this one), assuming that we're not just getting lots of reports from one or two users.

Can we look at getting this onto 1.9.1? (alternately is there an extension we should be blocking or something?).

Comment 125

[Wayne Mery (:wsmwk)]

(In reply to comment #124)
> This seems to be the bug for a top crash reported on Thunderbird (bug 540959
> duped to this one), assuming that we're not just getting lots of reports from
> one or two users.

still a Thunderbird topcrash even if 2/3 of crashes were duplicates by some users (and there are a couple sending 10+ crashes)

> Can we look at getting this onto 1.9.1? (alternately is there an extension we
> should be blocking or something?).

this doesn't totally answer your extension question, but there are plenty of crashes with no extensions - bp-b743351f-a8c4-4b5d-ba75-ed2552100126 for example (bp 989cd24d-12ac-4fcd-b4f8-287ec2100129 has just 2 mail-tweak and mintotray

so still much wanted for thunderbird 3.0/1.9.1

Comment 126

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #123)
> This was fixed on 1.9.2, but the fix isn't being felt until we get bug 538642
> on 1.9.2 as well. Updating whiteboard and keywords.

You did that in the wrong place. Bug 538642 is being used to track the fact that it's not fixed on Windows, and that is the bug that should (and does) block 1.9.2.2.

(In reply to comment #125)
> so still much wanted for thunderbird 3.0/1.9.1

Please file a new bug and nominate; I'm assuming that for 1.9.1 we would need a new patch.

Comment 127

[Mark Banner (:standard8)]

(In reply to comment #126)
> (In reply to comment #125)
> > so still much wanted for thunderbird 3.0/1.9.1
> 
> Please file a new bug and nominate; I'm assuming that for 1.9.1 we would need a
> new patch.

I reopened bug 540959 that was originally duped to this bug.

Comment 128

[msrajftw]

http://techonloop.com/how-to-reinstall-directx-11-repair/