554940 - -mfpmath=sse triggers useless crash in floor [@ floor | NS_floor | gfxMatrix::HasNonIntegerTranslation]

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Brad Jackson]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a4pre) Gecko/20100325 Firefox/3.7a4pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a4pre) Gecko/20100325 Firefox/3.7a4pre

Firefox trunk compiled with GCC flag -mfpmath=sse causes segfault on startup or intermittently on www.usatoday.com. The startup crash may be related to the default browser prompt.

Reproducible: Sometimes

Steps to Reproduce:
1. Compile trunk with -mfpmath=sse
2. Start Firefox
3. Crash at startup if not default browser or intermittent crash on www.usatoday.com or other random sites
Actual Results:  
Intermittent segfault

Expected Results:  
Should not crash

Will attach stack trace. I am unsure if this is a Firefox of GCC bug.

Comment 1

[Brad Jackson]

Attachment: Stacktrace of segfault

Comment 2

[timeless]

I'm willing to blame your compiler.

142 inline NS_HIDDEN_(double) NS_floor(double x)
143 {
144     return floor(x);

190     PRBool HasNonIntegerTranslation() const {
191         return HasNonTranslation() ||
192             !gfxUtils::FuzzyEqual(x0, NS_floor(x0 + 0.5)) ||
193             !gfxUtils::FuzzyEqual(y0, NS_floor(y0 + 0.5));
194     }

we're doing nothing remotely interesting here.

it's possible this is because of:
#56 0xb6eda977 in NS_InvokeByIndex_P ()
#57 0xb639ff19 in XPCWrappedNative::CallMethod (ccx=@0xbfc2f61c, 

where we aren't enforcing 2048 bit stack alignment or whatever insanity your compiler demands. (we already have bugs about trying to change the alignment to better suit the unpredictable demands of braindead compilers and linkers and third party libraries.) 

we have a general rule: If it hurts when you poke yourself in the eye, don't poke yourself in the eye.

if you're interested in stack alignment bugs, you can find the relevant bug, if you're just an optimization monkey, please stop.

Comment 3

[Brad Jackson]

Adding -mstackrealign prevents the crash, so the stack alignment theory seems correct. That flag also fixed a crash with -ftree-vectorize when I tested it in the past.

I now compile for size plus fortify and the stack protector flags that some Linux distros use in their builds, so I am still a bit of a "optimization monkey" as you say. I used to be a C++ programmer, but lost interest years ago and am no longer interested in coding much at that low of a level.

Comment 4

[timeless]

oh wow, there's a flag to fix this? nice. that's very useful to know about. i wonder if we could make a configure test to recognize when someone was stupid and forcibly add that flag....

Comment 5

[(not currently active) Ted Mielczarek]

I'm generally not terribly interested in trying to prevent all the ways you can shoot yourself in the foot by passing random flags to things. Preventing defaults from doing bad things is good, but there are just too many ways to shoot yourself for us to usefully prevent them all.

Comment 6

[timeless]

ted: i know, but this one is special because we get bugs from it quarterly, i think there's even currently a bug from intel about stack alignment.

Comment 7

[(not currently active) Ted Mielczarek]

If you can figure out a decent configure test, I guess I'd take it.