351181 - SIGFPE on component registration eating 100% cpu (probably amd64 specific)

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Gaspar Chiligarov]

User-Agent:       Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1a3) Gecko/20060903 Firefox/2.0a3
Build Identifier: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.8.1a3) Gecko/20060903 Firefox/2.0a3

On -CURRENT FreeBSD (as of 3 Sep 2006), amd64 system, Firefox also compiled for 64bits. 

On some components install (for instance, firebug), after browser restart (autoregistration step) - browser begin to eat 100% cpu and hangs in that state. 
kdump shows that it gots a lot of unhandled SIGFPE signals. This occurs both for optimized and not optimized builds of firefox.



Reproducible: Always

Steps to Reproduce:
on FreeBSD current, on amd64 processor install firebug extension. 
Actual Results:  
Building debug image and debugging discovered that it crashes in 
jsnum.c js_NewNumberValue function on checking JSDOUBLE_IS_INT(d, i). 
This occurs when d is equal to 4.9406564584124654e-324, which is probably (S)NaN? value on that athlon processor. 

debug printout added:
printf("HI: %x, LO: %x\n", JSDOUBLE_HI32(d), JSDOUBLE_LO32(d));

Just before getting signal it prints out HI: 0, LO: 1 - which is probably special value of double floating type.

It crashes on the last instruction in this block - floating point compare

0x000000000005d5a4 <js_NewNumberValue+132>:     cvttsd2si %xmm1,%edx
0x000000000005d5a8 <js_NewNumberValue+136>:     cvtsi2sd %edx,%xmm0
0x000000000005d5ac <js_NewNumberValue+140>:     ucomisd %xmm1,%xmm0



Expected Results:  
Fixing: avoid this case -- see the patch 

cat jsnum.c.diff 
664c664,667
<       if (JSDOUBLE_IS_INT(d, i) && INT_FITS_IN_JSVAL(i)) {
---
>       //printf("HI: %x, LO: %x\n", JSDOUBLE_HI32(d), JSDOUBLE_LO32(d));
> 
>       if ((!((JSDOUBLE_HI32(d) == 0) && (JSDOUBLE_LO32(d) == 1))) &&
>               JSDOUBLE_IS_INT(d, i) && INT_FITS_IN_JSVAL(i)) {

just avoid 

here it is a patch:

cat jsnum.c.diff 
664c664,667
<       if (JSDOUBLE_IS_INT(d, i) && INT_FITS_IN_JSVAL(i)) {
---
>       //printf("HI: %x, LO: %x\n", JSDOUBLE_HI32(d), JSDOUBLE_LO32(d));
> 
>       if ((!((JSDOUBLE_HI32(d) == 0) && (JSDOUBLE_LO32(d) == 1))) &&
>               JSDOUBLE_IS_INT(d, i) && INT_FITS_IN_JSVAL(i)) {

just avoid calling JSDOUBLE_IS_INT if we got NaN value.
probably this check should be moved inside a macro?

Comment 1

[Gaspar Chiligarov]

Forgot to mention - this fixed FireBug issues for me -- now it can setup jsDebugger interface component on start and works as expected. 

Comment 2

[Brendan Eich [:brendan]]

There are many NaN value.  They should all be quiet.  Instead of patching the code to catch one particular NaN and avoid getting a non-quiet exception, find out why NaNs aren't quiet.  They really have to be, for JS to work per ECMA-262, and for any Gecko-based app to browse the web.

/be

Comment 3

[Brendan Eich [:brendan]]

See the FIX_FPU macro conditionally defined in jsnum.c.  But the ideal fix is to use whatever compiler options might be necessary to get quiet NaNs.

/be

Comment 4

[Gaspar Chiligarov]

This patch worked for me:

--cut--
--- jsnum.c.orig	Sun Sep  3 02:32:50 2006
+++ jsnum.c	Sun Sep  3 14:50:43 2006
@@ -519,10 +519,19 @@
 
 #else
 
+#if defined(__FreeBSD__) 
+/*&& (__FreeBSD_version >= 503000)*/
+#include <fenv.h>
+/*#pragma STDC FENV_ACCESS ON*/
+#define FIX_FPU() (fedisableexcept(FE_ALL_EXCEPT))
+
+#else
+
 #define FIX_FPU() ((void)0)
 
 #endif
 
+#endif
 JSBool
 js_InitRuntimeNumberState(JSContext *cx)
 {
@@ -660,6 +669,7 @@
 js_NewNumberValue(JSContext *cx, jsdouble d, jsval *rval)
 {
     jsint i;
+	/* printf("HI: %x, LO: %x, NAN: %d\n", JSDOUBLE_HI32(d), JSDOUBLE_LO32(d), isnan(d)); */
 
 	if (JSDOUBLE_IS_INT(d, i) && INT_FITS_IN_JSVAL(i)) {
         *rval = INT_TO_JSVAL(i);
--cut--

One problem is that  fe* functions were introduced in FreeBSD in 5.3 version, and I cannot define this condition - you can see it commented you, because it always processes to false.

Comment 5

[Tanner M. Young [:tmyoung]]

Can the issue be reproduced in Firefox 3.5?

Comment 6

[Gaspar Chiligarov]

I switched from FreeBSD to Ubuntu this year, so I cannot test it on v3.5 on  FreeBSD, but I've been using Firefox ~3.0.4 or something like that on FreeBSD/amd64 and never hit that bug again.

So I assume it could be silently closed :)

/Gaspar