873334 - illegal instruction on startup with nightly

Status: RESOLVED FIXED

(Toolkit :: Startup and Profile System, defect)

Description

[M. Kristall]

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)

Comment 1

[M. Kristall]

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

Comment 2

[Robert Strong (they/them - no direct email)]

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

Comment 3

[Benjamin Smedberg]

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.

Comment 4

[M. Kristall]

(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

Comment 5

[Mike Hommey [:glandium]]

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

Comment 6

[M. Kristall]

(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

Comment 7

[Mike Hommey [:glandium]]

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

Comment 8

[Mike Hommey [:glandium]]

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

Comment 9

[Mike Hommey [:glandium]]

Attachment: Add -march=pentiumpro when building in x64 buildbot environments

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.

Comment 10

[Nathan Froyd [:froydnj]]

(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.

Comment 11

[Mike Hommey [:glandium]]

(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 12

[(not currently active) Ted Mielczarek]

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".

Comment 13

[Mike Hommey [:glandium]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/0a4f4f342acf

Comment 14

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/0a4f4f342acf