User Agent: Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0 (Beta/Release) Build ID: 20130401133155 Steps to reproduce: I updated nightly for the first time in a couple of days, then tried to start newly updated nightly Actual results: Instant illegal instruction (unlike with bug 858022 when it would finish starting up before crashing)

I should have mentioned that I am an old AMD CPU without SSE2

This is actually a bug in the application code and not app update.

Do you have links to your crash reports, or are you ok with debugging locally? I'd like to figure out exactly what instruction you can't handle (whether it's actually SSE2 or something else like CMOV). I believe that the official Linux builds are now i686 by default (not i386) and so it may just be that they don't support your processor, and you'd have to do a self-build. The other possibility is that this is a crash in JIT code and this is in fact a JS bug.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #3) this cpu is a 1.8GHz Duron (model 8 "Applebred"). it does support cmov flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow I'd like to say I'm ok with debugging locally (aside from compiling taking forever), but my local debug build does not crash; a newly downloaded nightly does the best I can do is: Program received signal SIGILL, Illegal instruction. 0x0804d25d in mozilla::ReadAhead(int, unsigned int, unsigned int) () which is different from the nightly from the 16th (when I reported the bug): Program received signal SIGILL, Illegal instruction. 0xb7111ceb in global constructors keyed to gfxSVGGlyphs.cpp () from /home/nsa/firefox/libxul.so

Can you provide a disassembly around the crash? (run under gdb and type "disassemble" when you crash)

(In reply to Mike Hommey [:glandium] from comment #5) The nightly from the 16th: Dump of assembler code for function _GLOBAL__I_gfxSVGGlyphs.cpp: 0xb7111ce0 <+0>: call 0xb68801d0 <__i686.get_pc_thunk.cx> 0xb7111ce5 <+5>: add $0x858efb,%ecx => 0xb7111ceb <+11>: xorpd %xmm0,%xmm0 0xb7111cef <+15>: push %ebp 0xb7111cf0 <+16>: mov %esp,%ebp 0xb7111cf2 <+18>: pop %ebp 0xb7111cf3 <+19>: movapd %xmm0,0xbb8c0(%ecx) 0xb7111cfb <+27>: movapd %xmm0,0xbb8d0(%ecx) 0xb7111d03 <+35>: ret Newer nightly: Dump of assembler code for function _ZN7mozilla9ReadAheadEijj: 0x0804d240 <+0>: push %ebp 0x0804d241 <+1>: mov %esp,%ebp 0x0804d243 <+3>: push %ebx 0x0804d244 <+4>: call 0x804b5b6 <__x86.get_pc_thunk.bx> 0x0804d249 <+9>: add $0x1c8a7,%ebx 0x0804d24f <+15>: sub $0x14,%esp 0x0804d252 <+18>: mov 0x10(%ebp),%eax 0x0804d255 <+21>: mov 0x8(%ebp),%edx 0x0804d258 <+24>: movd 0xc(%ebp),%xmm0 => 0x0804d25d <+29>: movq %xmm0,0x4(%esp) 0x0804d263 <+35>: mov %eax,0xc(%esp) 0x0804d267 <+39>: mov %edx,(%esp) 0x0804d26a <+42>: call 0x804a9c4 <readahead@plt> 0x0804d26f <+47>: add $0x14,%esp 0x0804d272 <+50>: pop %ebx 0x0804d273 <+51>: pop %ebp 0x0804d274 <+52>: ret

Both instructions are SSE2 and your CPU doesn't support SSE2.

That could very well be a fallout from the switch to gcc 4.7.

So, here is the deal: the default for our x86 gcc (be it 4.5 or 4.6) is -march=pentiumpro. The default for our x64 gcc with -m32 is -march=x86_64, and that enables -msse and -msse2. So we need to get back to the same -march value.

(In reply to Mike Hommey [:glandium] from comment #9) > So, here is the deal: the default for our x86 gcc (be it 4.5 or 4.6) is > -march=pentiumpro. The default for our x64 gcc with -m32 is -march=x86_64, > and that enables -msse and -msse2. So we need to get back to the same -march > value. That seems kind of bizarre. How did we configure the new gcc? ISTR that there's a --with-arch32 or somesuch to set the default sanely...maybe that's only in 4.8.

(In reply to Nathan Froyd (:froydnj) from comment #10) > (In reply to Mike Hommey [:glandium] from comment #9) > > So, here is the deal: the default for our x86 gcc (be it 4.5 or 4.6) is > > -march=pentiumpro. The default for our x64 gcc with -m32 is -march=x86_64, > > and that enables -msse and -msse2. So we need to get back to the same -march > > value. > > That seems kind of bizarre. How did we configure the new gcc? ISTR that > there's a --with-arch32 or somesuch to set the default sanely...maybe that's > only in 4.8. Mostly default flags. I'm pretty sure there's a flag to give a sane default, as debian gcc doesn't behave the same, but that won't change the gcc version already installed.

Comment on attachment 753433 [details] [diff] [review] Add -march=pentiumpro when building in x64 buildbot environments Review of attachment 753433 [details] [diff] [review]: ----------------------------------------------------------------- Oops. ::: build/unix/mozconfig.linux32 @@ +1,4 @@ > . "$topsrcdir/build/unix/mozconfig.linux" > > if test `uname -m` = "x86_64"; then > + # -march=pentiumpro is what our toolchain defaults to natively This comment is confusing. I think you mean to say "is what the 32-bit native toolchain defaults to".