If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

illegal instruction on startup with nightly

RESOLVED FIXED in mozilla24

Status

()

Toolkit
Startup and Profile System
--
critical
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: M. Kristall, Assigned: glandium)

Tracking

24 Branch
mozilla24
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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)
(Reporter)

Comment 1

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

Updated

4 years ago
Severity: normal → critical
See Also: → bug 858022
Component: Untriaged → Application Update
Product: Firefox → Toolkit
This is actually a bug in the application code and not app update.
Component: Application Update → Startup and Profile System

Comment 3

4 years ago
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.
(Reporter)

Comment 4

4 years ago
(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
(Assignee)

Comment 5

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

Comment 6

4 years ago
(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
(Assignee)

Comment 7

4 years ago
Both instructions are SSE2 and your CPU doesn't support SSE2.
(Assignee)

Comment 8

4 years ago
That could very well be a fallout from the switch to gcc 4.7.
(Assignee)

Updated

4 years ago
Blocks: 864262
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 9

4 years ago
Created attachment 753433 [details] [diff] [review]
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.
Attachment #753433 - Flags: review?(ted)
(Assignee)

Updated

4 years ago
Assignee: nobody → mh+mozilla
(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.
(Assignee)

Comment 11

4 years ago
(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".
Attachment #753433 - Flags: review?(ted) → review+
(Assignee)

Comment 13

4 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/0a4f4f342acf
https://hg.mozilla.org/mozilla-central/rev/0a4f4f342acf
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.