Issue 525751 in chromium: Illegal instruction SIGILL on start up

[chro...@googlecode.com]

Status: Unconfirmed
Owner: ----
Labels: Stability-Crash Pri-2 Via-Wizard Type-Bug OS-Linux

New issue 525751 by jared.wi...@gtempaccount.com: Illegal instruction
SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/44.0.2403.157 Safari/537.36

Steps to reproduce the problem:
1. Run google-chrome-unstable
2.
3.

What is the expected behavior?

What went wrong?
Illegal instruction

Crashed report ID:

How much crashed? Whole browser

Is it a problem with a plugin? N/A

Did this work before? N/A

Chrome version: 46.0.2490.4 Channel: dev
OS Version: Ubuntu 15.04
Flash Version: Shockwave Flash 18.0 r0

google-chrome-unstable_46.0.2486.0-1_amd64.deb is fine

Both later versions crash

google-chrome-unstable_46.0.2490.4-1_amd64.deb
google-chrome-unstable_46.0.2490.6-1_amd64.deb

--
You received this message because this project is configured to send all
issue notifications to this address.
You may adjust your notification preferences at:
https://code.google.com/hosting/settings

[chro...@googlecode.com]

Comment #2 on issue 525751 by jared.wi...@gtempaccount.com: Illegal

instruction SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Crash dump as requested

Attachments:
288d2bd7-05c0-1b6f-2ce5bd52-05aa780c.dmp 366 KB

[chro...@googlecode.com]

Updates:
Status: Untriaged
Cc: tha...@chromium.org

Comment #3 on issue 525751 by the...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Jared: The crash dump did not manage to capture the state of the thread
that actually crashed, so there's no stack trace to explain the exact state
in which the crash occurred.

Looking at the instruction where it crashed, it's LAHF. What kind of
Pentium 4 is this happening on? Is there an option to turn on
virtualization in the BIOS? If so, does turning that on help?

thakis: Did something change in Clang to allow LAHF instructions? People
with ~10 year old computers are going to have trouble with that.

[chro...@googlecode.com]

Comment #4 on issue 525751 by the...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Hmm, I ran: objdump --disassemble path/to/chrome |grep lahf

for a few sample chrome binaries. Chrome 32.0.1700.x did not contain any
lahf instructions, where as 38.0.2063.0 does. So does 44.0.2403.x. I don't
understand how this could have regressed between 46.0.2486.0 and
46.0.2490.4. Surely previous versions would have had the same problem?

[chro...@googlecode.com]

Comment #5 on issue 525751 by jared.wi...@gtempaccount.com: Illegal

instruction SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

It is a pretty old P4 that is doing this.

cat /proc/cpuinfo

processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 3
microcode : 0x5
cpu MHz : 2800.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl est cid cx16 xtpr
bugs :
bogomips : 6000.71
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4
model name : Intel(R) Pentium(R) 4 CPU 3.00GHz
stepping : 3
microcode : 0x5
cpu MHz : 2800.000
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 1
apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm
constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl est cid cx16 xtpr
bugs :
bogomips : 6000.71
clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:

[chro...@googlecode.com]

Comment #7 on issue 525751 by jared.wi...@gtempaccount.com: Illegal

instruction SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

The problem still exists in google-chrome-unstable_47.0.2498.0-1_amd64.deb

While the latest stable, google-chrome-stable_45.0.2454.85-1_amd64.deb, is
fine.

[chro...@googlecode.com]

Updates:
Labels: TE-NeedsFurtherTriage

Comment #8 on issue 525751 by ashej...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

(No comment was entered for this change.)

[chro...@googlecode.com]

Comment #9 on issue 525751 by renthra...@gmail.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

This problem is now the stable branch as of

google-chrome-stable_46.0.2490.71-1_amd64.deb

[chro...@googlecode.com]

Comment #10 on issue 525751 by the...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

That's unfortunate. So I know why it's happening but I don't understand why
it did not happen before with older builds. Can you try some builds from
the archive here

https://commondatastorage.googleapis.com/chromium-browser-continuous/index.html?prefix=Linux_x64/

between 343773 and 344925, to narrow down when it first started?

I don't have hardware to test with, so you'll have to do some of the
homework here. The other solution is to sacrifice this 10 year old P4 to
the computer gods. ;)

[chro...@googlecode.com]

Updates:
Cc: j...@chromium.org

Comment #15 on issue 525751 by h...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

> thakis/hans: Maybe the Clang roll in r344613 caused this? Can you check
> to see if something changed there that affects old P4s / LAHF
> instructions?

Yes:

http://llvm.org/viewvc/llvm-project?rev=244503&view=rev
"x86: Emit LAHF/SAHF instead of PUSHF/POPF"

[chro...@googlecode.com]

Updates:
Labels: -TE-NeedsFurtherTriage

Comment #16 on issue 525751 by the...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Horray, progress.

[chro...@googlecode.com]

Comment #17 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

For context:

http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150810/293071.html

Did lahf/sahf code generation never happen before?

We're playing bug whack-a-mole at this point: my patch fixes an actual bug
as well, adding a new one that seemed inconsequential because other code
assumed lahf/sahf was OK.

The mailing list post has a proposed patch to start teaching LLVM about
CPUs without lahf/sahf, but that would take us back to the buggy behavior.

[chro...@googlecode.com]

Comment #19 on issue 525751 by tha...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Wow, that's much higher than I would've expected. Crashing on startup is
probably worse than the actual bug you fixed, on machines that don't have
lahf…

[chro...@googlecode.com]

Comment #20 on issue 525751 by the...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

jfb: So any plans to address this?

[chro...@googlecode.com]

Comment #21 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

I'm away for ~1 month, with 2 weeks remaining (conferences these 2 week,
and vacation for the next two weeks). I don't think this can just be fixed
easily, or I would already have done so. I did post a patch that would get
us partway there. Remember that the breakage already existed in LLVM, and
the patch was fixing a flag tracking bug around cmpxchg (LLVM can't track
flag+register from it), which is pretty hard to narrow.

It started as a way to remove pushf/popf which have security and
performance implications, but at this point in time that patch has had
quite a few other ramifications.

[chro...@googlecode.com]

Comment #23 on issue 525751 by tais.han...@gmail.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Chrome 46 also crashes with SIGILL on my old Ubuntu 14.04 box. Prior
versions worked.

$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 5
model name : AMD Opteron(tm) Processor 248
stepping : 10
microcode : 0x3a
...

[chro...@googlecode.com]

Comment #25 on issue 525751 by e...@schultzter.ca: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

I don't know if you need another lscpu dump, but I'm having the same issue
on computer. Originally with -beta and when I upgraded today I've got the
same issue on -stable (Arch Linux).

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 2
On-line CPU(s) list: 0,1
Thread(s) per core: 2
Core(s) per socket: 1
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 15
Model: 4
Model name: Intel(R) Pentium(R) 4 CPU 3.00GHz
Stepping: 1
CPU MHz: 2992.483
BogoMIPS: 5987.33
L1d cache: 16K
L2 cache: 1024K
NUMA node0 CPU(s): 0,1
Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge

mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall

nx lm constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl cid cx16 xtpr

[chro...@googlecode.com]

Comment #26 on issue 525751 by panos.ka...@gmail.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

If the following command returns nothing, your processor does not support
the LAHF instruction and you are also affected:

$ grep -i lahf /proc/cpuinfo

I plugged my hard disk on another computer and the issue is no longer
reproduced on a 4-cores Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz.

[chro...@googlecode.com]

Comment #29 on issue 525751 by vanantwe...@gmail.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Hi all, is there an ETA on the fix? Chrome 46 appears to be crashing too
much on Linux and unfortunately this is by now the stable version.

[chro...@googlecode.com]

Comment #30 on issue 525751 by o...@swiftserve.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

It is also mentioned here:
https://code.google.com/p/chromium/issues/detail?id=544160

[chro...@googlecode.com]

Comment #31 on issue 525751 by tim.woch...@gmail.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

This also appears on a Pentium D Dual Core :-/

processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 4

model name : Intel(R) Pentium(R) D CPU 3.00GHz
stepping : 4
microcode : 0x6
cpu MHz : 3000.000
cache size : 1024 KB

physical id : 0
siblings : 2
core id : 0

cpu cores : 2

apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat

pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm

constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl est cid cx16 xtpr
bugs :

bogomips : 5984.99

clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 4

model name : Intel(R) Pentium(R) D CPU 3.00GHz
stepping : 4
microcode : 0x6
cpu MHz : 2800.000
cache size : 1024 KB

physical id : 0
siblings : 2

core id : 1
cpu cores : 2

apicid : 1
initial apicid : 1
fpu : yes
fpu_exception : yes
cpuid level : 5
wp : yes

flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat

pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm

constant_tsc pebs bts nopl pni dtes64 monitor ds_cpl est cid cx16 xtpr
bugs :

bogomips : 5984.99

clflush size : 64
cache_alignment : 128
address sizes : 36 bits physical, 48 bits virtual
power management:

[chro...@googlecode.com]

Comment #32 on issue 525751 by tim.sav...@gmail.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

That's unfortunate. The CPU in my Dell seems to be the 945, which is in the
Presler family. Yours appears to be a 830, which is in the Smithfield
family, judging by the 1Mb cache size vs. 2Mb in the later Presler chips.

So those looking to upgrade their processor to gain the LAHF features
should take extra care to ensure their upgrade candidate does indeed have
the requisite feature set.

I believe some computers that shipped with a Pentium 4 or Pentium D can
also be upgraded to early Core series processors, but definitely not all. I
have a Dell Dimension 9150 that came with a Pentium 4, which can support a
Pentium D, but not a Core series CPU. The fore mentioned Optiplex 745 can
however be upgraded to a Core2 Duo or even Core2 Quad.

If going this route, it will take careful research to ensure your computer
can support such an upgrade, and that the newer processor actually does
include the LAHF instructions.

[chro...@googlecode.com]

Comment #33 on issue 525751 by tim.woch...@gmail.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Ah, most Pentium D boards lack some circuitry required for the core
processor, for example, the processor in my Dell XPS 400. So while the
socket might be the same, it will not support the CPU.

[chro...@googlecode.com]

Updates:
Owner: j...@chromium.org

Comment #34 on issue 525751 by tha...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Hans points out that this is happens in 64-bit binaries; I thought that
this was 32-bit for some reason.

This will likely be a huge problem if we switch compilers on Windows. jf,
if this is tricky to fix can we revert your thing for now? Being able to
run a program is probably more important than whatever bug your CL fixes…

[chro...@googlecode.com]

Comment #35 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

This is still on my post-vacation todo list, I'll get to it soon. LLVM
already generated lahf/sahf prior to my patch, so it's just a question of
Chrome hitting that code now which leads me to believe that a simple revert
isn't what you want. Overall, these instructions get emitted when LLVM gets
confused about x86 flag liveness, so we're kind of in a pile of breakage...
I'd like to reduce that pile over time.

[chro...@googlecode.com]

Comment #37 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

I can't count and was off, the functions are actually these:
asm_AES_cbc_encrypt
gcm_ghash_avx

[chro...@googlecode.com]

Comment #38 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

And this is incorrect, because these are hand-written .S files with .value
content, which confuses objdump :-)

It looks like there are no lahf/sahf instructions in my debug build of
Chrome on Linux.

I'll have to figure out why my build isn't getting the lahf/sahf
instructions generated, it may need to be a release build.

[chro...@googlecode.com]

Comment #39 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

The release build is more helpful with 140 occurrences of the instructions
in the following functions:
asm_AES_cbc_encrypt
browser_sync::SyncBackendRegistrar::RemoveWorker(syncer::ModelSafeGroup)
cc::ResourceProvider::UnlockForRead(unsigned int)

content::PepperCompositorHost::OnHostMsgCommitLayers(ppapi::host::HostMessageContext*,
std::vector<ppapi::CompositorLayerData,
std::allocator<ppapi::CompositorLayerData> > const&, bool)
CPDF_ClipPath::AppendPath(CPDF_Path, int, int)
CPDF_ClipPathData::CPDF_ClipPathData(CPDF_ClipPathData const&)
CPDF_StreamContentParser::Handle_ShowText_Positioning()
gcm_ghash_avx
gfx::TimeElapsedTimerQuery::EndQuery(gfx::GPUTimingImpl*,
scoped_refptr<gfx::QueryResult>)
GrBatchAtlas::GrBatchAtlas(GrTexture*, int, int)
GrLayerAtlas::GrLayerAtlas(GrTextureProvider*, GrPixelConfig,
GrSurfaceFlags, SkTSize<int> const&, int, int)
icu_54::CanonicalIterator::getEquivalents(icu_54::UnicodeString const&,
int&, UErrorCode&)
icu_54::CanonicalIterator::setSource(icu_54::UnicodeString const&,
UErrorCode&)
icu_54::createArrayCopy(icu_54::Formattable const*, int)
icu_54::DateFormatSymbols::copyData(icu_54::DateFormatSymbols const&)
icu_54::DateFormatSymbols::createZoneStrings(icu_54::UnicodeString const*
const*)
icu_54::DateFormatSymbols::initializeData(icu_54::Locale const&, char
const*, UErrorCode&, signed char)
icu_54::initField(icu_54::UnicodeString**, int&, UResourceBundle const*,
UErrorCode&)
icu_54::isAvailableLocaleListInitialized(UErrorCode&)
icu_54::locale_available_init()
icu_54::MessageFormat::parse(int, icu_54::UnicodeString const&,
icu_54::ParsePosition&, int&, UErrorCode&) const
icu_54::RuleBasedNumberFormat::init(icu_54::UnicodeString const&,
icu_54::LocalizationInfo*, UParseError&, UErrorCode&)
leveldb::NewMergingIterator(leveldb::Comparator const*,
leveldb::Iterator**, int)
libusb_unref_device
NaClSrpcMessageChannelReceive
SkFontStyleSet_FC::SkFontStyleSet_FC(_FcPattern**, int)
SkTHashTable<SkTHashMap<SkPath, int, SkPictureRecord::PathHash>::Pair,
SkPath, SkTHashMap<SkPath, int,
SkPictureRecord::PathHash>::Pair>::resize(int)

SkTypeface_FreeType::onGetAdvancedTypefaceMetrics(SkTypeface::PerGlyphInfo,
unsigned int const*, unsigned int) const

webrtc::AudioEncoderG722::AudioEncoderG722(webrtc::AudioEncoderG722::Config
const&)
webrtc::Expand::Expand(webrtc::BackgroundNoise*, webrtc::SyncBuffer*,
webrtc::RandomVector*, webrtc::StatisticsCalculator*, int, unsigned long)
webrtc::intelligibility::VarianceArray::VarianceArray(unsigned long,
webrtc::intelligibility::VarianceArray::StepType, unsigned long, float)
webrtc::WPDTree::WPDTree(unsigned long, float const*, float const*,
unsigned long, int)

That's a bit more spread out, I'll take a look next week.

[chro...@googlecode.com]

Comment #40 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

My development desktop died over the weekend, I'll have to setup a much
slower laptop to continue investigating. I should get a new desktop soon,
but I just wanted to update everyone on slow progress (compounded by
thanksgiving)... Sorry about that.

[chro...@googlecode.com]

Comment #42 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

I looked a bit more and I think the fundamental issue is that after machine
sinking the MI code looks like:

DEC32m %RIP, 1, %noreg, <ga:@L>, %noreg, %EFLAGS<imp-def>;
mem:ST4[@L] LD4[@L]
%vreg1<def> = COPY %EFLAGS; GR64:%vreg1
%EFLAGS<def> = COPY %vreg1; GR64:%vreg1
JNE_1 <BB#1>, %EFLAGS<imp-use>

That's pretty silly. I think teaching PeepholeOptimizer to get rid of the
extra copies is the right approach. The code currently ignores physical
registers, so I started a patch to teach it to ignore idempotent physical
register moves such as this without otherwise being smart about physical
registers, but it needs to be aware of a few tricky corner cases. I'm a bit
wary of missing some odd expectations that non-x86 targets may have, I'll
see how that works out for me.

I'll get back to this after thanksgiving.

[chro...@googlecode.com]

Comment #50 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

One of the related patches has landed:
http://reviews.llvm.org/D15157

There's still work needed in teaching LLVM to be less silly. In many cases
SETx should be used. I'd appreciate help on this, as I have limited
bandwidth to work on the other code generation issues. It's worth noting
that GCC does much better than LLVM in these cases.

[chro...@googlecode.com]

Comment #51 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

I forgot to reiterate: another other option is still to teach LLVM a new
-mattr. I liked to a patch that does this above, it does need a list of CPU
targets to be functional.

[chro...@googlecode.com]

Comment #52 on issue 525751 by h...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

> I forgot to reiterate: another other option is still to teach LLVM a new
> -mattr. I liked to a patch that does this above, it does need a list of
> CPU targets to be functional.

I'm looking into this today.

[chro...@googlecode.com]

Comment #53 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Thanks Hans, let me know if I can help. I'll be traveling next week but
will be online MUC time.

I think the patch needs a bit of rebasing, a list of old CPUs without
lahf/sahf, and exposed the older bug from 2012.

[chro...@googlecode.com]

Comment #55 on issue 525751 by j...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Hans: I wrote a skeleton patch for -mattr:
http://reviews.llvm.org/D15239

[chro...@googlecode.com]

Comment #56 on issue 525751 by h...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

> Hans: I wrote a skeleton patch for -mattr: http://reviews.llvm.org/D15239

Heh, I just uploaded mine: http://reviews.llvm.org/D15240 :-)

[chro...@googlecode.com]

Comment #58 on issue 525751 by sthprk1...@yahoo.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

@#47 According to my research, VT-x is not supported by Pentium D 8xx
processors. It is however supported by Pentium D 9x0. A 920 should support
VT-x.

[chro...@googlecode.com]

Comment #62 on issue 525751 by ThusSpak...@aol.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

@ #58 sthprk1...@yahoo.com: u r correct, but as I said, there were TWO
cpu's both designated as Intel® Pentium® D Processor 920 (idk how or why);
one has VT-x, the other does not ( reference:
http://ark.intel.com/products/series/20864/Intel-Pentium-D-Processor-900-Series
). Just my 'luck', I got the one without ... (terminal command "$ grep -i
lahf /proc/cpuinfo" returns no response, so ... UNsupported). As I also
said, "/me is stupid ya' know", so will someone kindly post the process to
revert to that last viable Google Chrome, version 45.0.2454.101 (64-bit) he
said, as well as 'freeze-lock' it so that it cannot 'update'? ... or just
post a suitable sitelink that walks-me-thru-it? ... & Thanks.

[chro...@googlecode.com]

Comment #65 on issue 525751 by ThusSpak...@aol.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

TYVM @ #63 anpes...@gmail.com, & @ #64 thestig@chromium. As I said b4, "not
a power-user", never was, nor sadly ever will be. Only been using Linux
since last year, but have no regrets at all whatsoever (other than this
browser bug here; & that's not Linux's fault). Win?doze is entirely so
vulnerable & the last versions I used so labor-intensive to keep secure &
running properly, it got me completely fed the f*** up. Honestly, how can
an OS that literally destroys itself as u use it NOT have the necessary
tools built in (&/or automated) to fix itself (registry
errors/defragmenting registry/etc), yet still be the most used OS in the
world? ... /me scratches head ... shrugs ... says goodbye to marketing bs &
monthly 2nd-party service fees (...hmmmm...) ... & exclusively uses Linux
now .... ( & thanks again, peeps ... Linux community always comes thru :)

[chro...@googlecode.com]

Comment #69 on issue 525751 by renthra...@gmail.com: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Just a heads up for people unaware, latest google-chrome-unstable
49.0.2587.3-1 has the fix for this.

[chro...@googlecode.com]

Comment #70 on issue 525751 by gvanho...@skynet.be: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

49.0.2587.3-1 works fine. Thanks for the fix, well done.

[chro...@googlecode.com]

Updates:
Cc: the...@chromium.org ranjit...@chromium.org melody...@chromium.org
kkitaj...@chromium.org tin...@chromium.org

Comment #71 on issue 525751 by the...@chromium.org: Illegal instruction

SIGILL on start up
https://code.google.com/p/chromium/issues/detail?id=525751

Issue 544160 has been merged into this issue.