chromium-browser crashed with SIGSEGV

Bug #1378627 reported by Daniel Holbach on 2014-10-08
This bug affects 39 people
Affects Status Importance Assigned to Milestone
Chromium Browser
Won't Fix
chromium-browser (Debian)
Fix Released
chromium-browser (Fedora)
Won't Fix
chromium-browser (Ubuntu)
Chad Miller

Bug Description

No idea what happened.

ProblemType: Crash
DistroRelease: Ubuntu 14.10
Package: chromium-browser 37.0.2062.94-0ubuntu1~pkg1065
ProcVersionSignature: Ubuntu 3.16.0-21.28-generic 3.16.4
Uname: Linux 3.16.0-21-generic x86_64
ApportVersion: 2.14.7-0ubuntu3
Architecture: amd64
CrashCounter: 1
CurrentDesktop: Unity
Date: Wed Oct 8 07:12:48 2014
ExecutablePath: /usr/lib/chromium-browser/chromium-browser
InstallationDate: Installed on 2013-12-22 (289 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20131221)
ProcCmdline: chromium-browser\ --type=gpu-process\ --channel=3043.0.199670400\ --supports-dual-gpus=false\ --gpu-driver-bug-workarounds=1,11,15\ --disable-accelerated-video-decode\ --gpu-vendor-id=0x8086\ --gpu-device-id=0x0126\ --gpu-driver-vendor\ --gpu-driver-versi
 Segfault happened at: 0x7fc0e6b1963f: mov 0x1f8(%rax),%r15
 PC (0x7fc0e6b1963f) ok
 source "0x1f8(%rax)" (0x000001f8) not located in a known VMA region (needed readable region)!
 destination "%r15" ok
SegvReason: reading NULL VMA
Signal: 11
SourcePackage: chromium-browser
 ?? () from /usr/lib/x86_64-linux-gnu/dri/
 ?? () from /usr/lib/x86_64-linux-gnu/dri/
 ?? () from /usr/lib/chromium-browser/libs/
 ?? () from /usr/lib/chromium-browser/libs/
 ?? () from /usr/lib/chromium-browser/libs/
Title: chromium-browser crashed with SIGSEGV
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm autopilot cdrom dip lpadmin plugdev sambashare scanner sudo
modified.conffile..etc.default.chromium.browser: [deleted]
mtime.conffile..etc.chromium.browser.default: 2014-09-14T18:16:36.315577

In current stable you have to override the blacklist for it to enable gpu acceleration anyway, so this is more of a feature request to investigate why this happens with dri3 but not with dri2. For non-working webgl this is probably a little bit more serious.

On current google-chrome-unstable on a fresh profile with default settings gpu acceleration is enabled.
When it is manually enabled via chrome://flags and checking "Override software rendering list", this has happened at least since one or two stable versions, probably always.


$ google-chrome-unstable
ATTENTION: default value of option force_s3tc_enable overridden by environment.
ATTENTION: option value of option force_s3tc_enable ignored.
[20081:20081:0724/] Could not send GpuCommandBufferMsg_Initialize.
[20081:20081:0724/] CommandBufferProxy::Initialize failed.
[20081:20081:0724/] Failed to initialize command buffer.

this is repeated two times and chrome://gpu has these Log Messages:

GpuProcessHostUIShim: The GPU process crashed!
GpuProcessHostUIShim: The GPU process crashed!
GpuProcessHostUIShim: The GPU process crashed!

But with LIBGL_DRI3_DISABLE=1 google-chrome-unstable it works without issues.

Ivy Bridge, xorg 1.16, xf86-video-intel with sna and mesa both from recent git.

Version-Release number of selected component:

Additional info:
reporter: libreport-2.2.2
backtrace_rating: 4
cmdline: cheese
crash_function: get_stencil_miptree
executable: /usr/bin/cheese
kernel: 3.15.4-200.fc20.x86_64
runlevel: N 5
type: CCpp
uid: 1000

Truncated backtrace:
Thread no. 1 (10 frames)
 #0 get_stencil_miptree at brw_misc_state.c:257
 #1 brw_workaround_depthstencil_alignment at brw_misc_state.c:273
 #2 brw_clear at brw_clear.c:231
 #3 cogl_framebuffer_clear4f at ./cogl-framebuffer.c:374
 #4 cogl_framebuffer_clear at ./cogl-framebuffer.c:442
 #5 cogl_clear at ./cogl.c:87
 #6 _clutter_stage_do_pick at ./clutter-stage.c:1583
 #7 _clutter_input_device_update at ./clutter-input-device.c:899
 #8 _clutter_process_event_details at ./clutter-main.c:2453
 #9 _clutter_process_event at ./clutter-main.c:2777

Created attachment 921613
File: backtrace

Created attachment 921614
File: cgroup

Created attachment 921615
File: core_backtrace

Created attachment 921616
File: dso_list

Created attachment 921617
File: environ

Created attachment 921618
File: exploitable

Created attachment 921619
File: limits

Created attachment 921620
File: maps

Created attachment 921621
File: open_fds

Created attachment 921622
File: proc_pid_status

Created attachment 921623
File: var_log_messages

It's more or less intel specific. With (dri3) offloading to a radeonsi GPU all the gpu stuff works. But directly running it on intel doesn't.

On different intel hardware I can confirm this bug. LIBGL_DRI3_DISABLE=1 fixed the problem, thanks to Haag for the fix.

OpenSUSE Factory AMD64
Information [ 31.368] Current Operating System: Linux OpenSUSE.Linux 3.16.0-rc7-2-desktop #1 SMP PREEMPT Wed Jul 30 09:38:03 UTC 2014 (9b5a5f0) x86_64
 Information [ 31.462] compiled for 1.16.0, module version = 2.99.914
 Information X.Org X Server 1.16.0
GPU: Intel GM45 CPU: Pentium(R) Dual-Core CPU T4200 @ 2.00GHz

It doesn't crash with LIBGL_DRI3_DISABLE=1.


I've tried Mesa master (76f687d5a5be9d3bce8d05bcfef97a3d74ca1f18) and xf86-video-intel master (f5469681b620d9d6ccaf53e92ed31f931cb03b0d), but it's the same.

Core was generated by `/opt/google/chrome-unstable/chrome --type=gpu-process --channel=2180.0.73132887'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 get_stencil_miptree (irb=<optimized out>) at brw_misc_state.c:225
225 if (irb->mt->stencil_mt)
(gdb) bt
#0 0x00007f80fb33a51f in brw_workaround_depthstencil_alignment (irb=<optimized out>) at brw_misc_state.c:225
#1 0x00007f80fb33a51f in brw_workaround_depthstencil_alignment (brw=0x3f6385fa2028, clear_mask=clear_mask@entry=50) at brw_misc_state.c:241
#2 0x00007f80fb2f09d0 in brw_clear (ctx=0x3f6385fa2028, mask=50) at brw_clear.c:235
#3 0x00007f8114982816 in ()
#4 0x0000000000000000 in ()
(gdb) up
#1 brw_workaround_depthstencil_alignment (brw=0x1fca0ea81028, clear_mask=clear_mask@entry=50) at brw_misc_state.c:241
241 struct intel_mipmap_tree *stencil_mt = get_stencil_miptree(stencil_irb);
(gdb) p *(struct intel_renderbuffer *)(brw->ctx->DrawBuffer->Attachment[BUFFER_DEPTH].Renderbuffer)
$11 = {Base = {Base = {Mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
        __size = '\000' <repeats 39 times>, __align = 0}, ClassID = 305419896, Name = 0, Label = 0x0, RefCount = 1, Width = 0, Height = 0, Depth = 0, Purgeable = 0 '\000',
      AttachedAnytime = 0 '\000', NeedsFinishRenderTexture = 0 '\000', NumSamples = 0 '\000', InternalFormat = 6402, _BaseFormat = 6402, Format = MESA_FORMAT_Z24_UNORM_X8_UINT, TexImage = 0x0,
      Delete = 0x7f41ed700240 <intel_delete_renderbuffer>, AllocStorage = 0x7f41ed701480 <intel_alloc_private_renderbuffer_storage>}, Buffer = 0x0, Map = 0x0, RowStride = 0, ColorType = 0},
  mt = 0x0, singlesample_mt = 0x0, mt_level = 0, mt_layer = 0, layer_count = 1, draw_x = 0, draw_y = 0, need_downsample = false, need_map_upsample = false, singlesample_mt_is_tmp = false}

The crash happens since mt is 0, but other members looks strange (Width, Height, ...).

Sorry, I printed the wrong attachment, but it's almost the same :
(gdb) p *(struct intel_renderbuffer *)(brw->ctx->DrawBuffer->Attachment[BUFFER_STENCIL].Renderbuffer)
$1 = {Base = {Base = {Mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}},
        __size = '\000' <repeats 39 times>, __align = 0}, ClassID = 305419896, Name = 0, Label = 0x0, RefCount = 1, Width = 0, Height = 0, Depth = 0, Purgeable = 0 '\000',
      AttachedAnytime = 0 '\000', NeedsFinishRenderTexture = 0 '\000', NumSamples = 0 '\000', InternalFormat = 6401, _BaseFormat = 6401, Format = MESA_FORMAT_S_UINT8, TexImage = 0x0, Delete =
    0x7f044aa94240 <intel_delete_renderbuffer>, AllocStorage = 0x7f044aa95480 <intel_alloc_private_renderbuffer_storage>}, Buffer = 0x0, Map = 0x0, RowStride = 0, ColorType = 0}, mt = 0x0,
  singlesample_mt = 0x0, mt_level = 0, mt_layer = 0, layer_count = 1, draw_x = 0, draw_y = 0, need_downsample = false, need_map_upsample = false, singlesample_mt_is_tmp = false}

Chrome 38 beta crashes on start-up in if dri3 is enabled with:
sandy bridge, xserver 1.16, driver 2.99.916, mesa 10.2.7

Core was generated by `/usr/lib64/chromium-browser/chrome --type=gpu-process --channel=85383.0.1648497'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000032b4096f237 in brw_workaround_depthstencil_alignment () from /usr/lib64/dri/
(gdb) bt
#0 0x0000032b4096f237 in brw_workaround_depthstencil_alignment () from /usr/lib64/dri/
#1 0x0000032b40911888 in brw_clear () from /usr/lib64/dri/
#2 0x0000007c4e294af9 in gpu::gles2::GLES2DecoderImpl::Initialize(scoped_refptr<gfx::GLSurface> const&, scoped_refptr<gfx::GLContext> const&, bool, gfx::Size const&, gpu::gles2::DisallowedFeatures const&, std::vector<int, std::allocator<int> > const&) ()
#3 0x0000007c4e2491ce in content::GpuCommandBufferStub::OnInitialize(base::FileDescriptor, IPC::Message*) ()
#4 0x0000007c4e24ab4e in content::GpuCommandBufferStub::OnMessageReceived(IPC::Message const&) ()
#5 0x0000007c4e236c15 in content::MessageRouter::RouteMessage(IPC::Message const&) ()
#6 0x0000007c4e243c9a in content::GpuChannel::HandleMessage() ()
#7 0x0000007c4b5cb0f3 in base::debug::TaskAnnotator::RunTask(char const*, char const*, base::PendingTask const&) ()
#8 0x0000007c4b58ab18 in base::MessageLoop::RunTask(base::PendingTask const&) ()
#9 0x0000007c4b58ada9 in base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) ()
#10 0x0000007c4b58c56e in base::MessageLoop::DoWork() ()
#11 0x0000007c4b5c35eb in base::MessagePumpGlib::Run(base::MessagePump::Delegate*) ()
#12 0x0000007c4b59d9a4 in base::RunLoop::Run() ()
#13 0x0000007c4b5890cc in base::MessageLoop::Run() ()
#14 0x0000007c4e11bd3d in content::GpuMain(content::MainFunctionParams const&) ()
#15 0x0000007c4b538f97 in content::ContentMainRunnerImpl::Run() ()
#16 0x0000007c4b537a2b in content::ContentMain(content::ContentMainParams const&) ()
#17 0x0000007c4aff31fb in ChromeMain ()
#18 0x0000032b46b03f1b in __libc_start_main () from /lib64/
#19 0x0000007c4aff3079 in _start ()

Download full text (10.6 KiB)

Oh right, I had noticed that the gpu threads are segfaulting, but totally forgot that it could be relevant here.

Ivy Bridge here:

Core was generated by `/opt/google/chrome-unstable/chrome --type=gpu-process --channel=21942.4.5215851'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f84164044b8 in get_stencil_miptree (irb=0xf09fc2270b0) at brw_misc_state.c:225
225 if (irb->mt->stencil_mt)
(gdb) bt full
#0 0x00007f84164044b8 in get_stencil_miptree (irb=0xf09fc2270b0) at brw_misc_state.c:225
No locals.
#1 0x00007f8416404551 in brw_workaround_depthstencil_alignment (brw=0xf09fd940030, clear_mask=50) at brw_misc_state.c:241
        ctx = 0xf09fd940030
        fb = 0xf09fea11200
        rebase_depth = false
        rebase_stencil = false
        depth_irb = 0xf09fc22af20
        stencil_irb = 0xf09fc2270b0
        depth_mt =...

For the people only reading this bug report:

In IRC keithp found the cause.
With dri3 temporary files are created with O_TMPFILE.
The chromium sandbox does not allow creating temporary files with O_TMPFILE.

So another workaround for now is to use chromium/chrome with the --no-sandbox option (which will possibly reduce security).

There's a corresponding bugreport at chromium that was not publicly visible before, but now is:

Close this with NOTOURBUG/WONTFIX?

Daniel Holbach (dholbach) wrote :

 get_stencil_miptree (irb=<optimized out>) at ../../../../../../../src/mesa/drivers/dri/i965/brw_misc_state.c:225
 brw_workaround_depthstencil_alignment (brw=0x10bb12cc8028, clear_mask=clear_mask@entry=50) at ../../../../../../../src/mesa/drivers/dri/i965/brw_misc_state.c:241
 brw_clear (ctx=0x10bb12cc8028, mask=50) at ../../../../../../../src/mesa/drivers/dri/i965/brw_clear.c:235
 gpu::gles2::GLES2DecoderImpl::Initialize (this=0x10bb11cb8f00, surface=..., context=..., offscreen=<optimized out>, size=..., disallowed_features=..., attribs=...) at ../../gpu/command_buffer/service/
 content::GpuCommandBufferStub::OnInitialize (this=this@entry=0x10bb12d04e00, shared_state_handle=..., reply_message=0x10bb11ccbdc0) at ../../content/common/gpu/

Changed in chromium-browser (Ubuntu):
importance: Undecided → Medium
tags: removed: need-amd64-retrace
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in chromium-browser (Ubuntu):
status: New → Confirmed
C de-Avillez (hggdh2) wrote :

happened (twice,so far) on restart.

information type: Private → Public
jerrylamos (jerrylamos) wrote :

BTW, same or similar bug occurs on Google Chrome which is not a Ubuntu program hence un-reportable on launchpad.

tags: added: bugpattern-needed
jerrylamos (jerrylamos) wrote :

Also occurs with ubuntu chromium browser on utopic gnome 3.12 kernel 3.16.0-22

inferrna (inferrna) wrote :

I've got an error this way: on just started system load chromium by mistake and exit it before its window fully appeared.

Mike (0x656b694d) wrote :

Happens to me every time I switch a user.

It's getting fixed in chromium, so no action is necessary for mesa:
"who has the long-term fix almost ready."

I suggest keeping this here open until chromium is actually fixed and then closing it.

I don't know why, but doesn't crash any more now.
It could be any update to the given packages, so I don't know if the root cause is fixed, or if some change just avoids the problem.

Colan Schwartz (colan) wrote :

Happens almost every time I click on a link in Thunderbird. Instead of opening the link in a new tab, it simply crashes.

jerrylamos (jerrylamos) wrote :

Occurs when I close Chromium.

Nate Finch (natefinch) wrote :

I get this on startup when chrome is running in the background. And then tabs in chrome randomly crash. Only happened after upgrading to utopic, same chrome version otherwise.... booting to the kernel from trusty doesn't help either.

*** This bug has been marked as a duplicate of bug 77402 ***

Resolved upstream - their sandbox allows the creation of the necessary files now (at least in testing releases).

Chad Miller (cmiller) on 2015-01-15
Changed in chromium-browser (Ubuntu):
assignee: nobody → Chad Miller (cmiller)
Robert Hooker (sarvatt) wrote :

Can anyone reproduce this with mesa 10.3.7 in this PPA? (note: it will take about an hour to build and publish). You can remove it after with sudo ppa-purge ppa:sarvatt/sru1.

Chad Miller (cmiller) on 2015-02-03
Changed in chromium-browser (Ubuntu):
status: Confirmed → Fix Committed
Changed in chromium-browser (Debian):
status: Unknown → Confirmed
Changed in mesa:
importance: Unknown → Medium
status: Unknown → Invalid

*** Bug 82793 has been marked as a duplicate of this bug. ***

Changed in mesa:
importance: Medium → Unknown
status: Invalid → Unknown
Changed in mesa:
importance: Unknown → Medium
status: Unknown → Won't Fix
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package chromium-browser - 40.0.2214.94-0ubuntu1.1120

chromium-browser (40.0.2214.94-0ubuntu1.1120) vivid; urgency=medium

  * Upstream release 40.0.2214.94.
  * Upstream release 40.0.2214.93.
  * Upstream release 40.0.2214.91. (LP: #1414753)
    - CVE-2014-7923: Memory corruption in ICU.
    - CVE-2014-7924: Use-after-free in IndexedDB.
    - CVE-2014-7925: Use-after-free in WebAudio.
    - CVE-2014-7926: Memory corruption in ICU.
    - CVE-2014-7927: Memory corruption in V8.
    - CVE-2014-7928: Memory corruption in V8.
    - CVE-2014-7930: Use-after-free in DOM.
    - CVE-2014-7931: Memory corruption in V8.
    - CVE-2014-7929: Use-after-free in DOM.
    - CVE-2014-7932: Use-after-free in DOM.
    - CVE-2014-7933: Use-after-free in FFmpeg.
    - CVE-2014-7934: Use-after-free in DOM.
    - CVE-2014-7935: Use-after-free in Speech.
    - CVE-2014-7936: Use-after-free in Views.
    - CVE-2014-7937: Use-after-free in FFmpeg.
    - CVE-2014-7938: Memory corruption in Fonts.
    - CVE-2014-7939: Same-origin-bypass in V8.
    - CVE-2014-7940: Uninitialized-value in ICU.
    - CVE-2014-7941: Out-of-bounds read in UI.
    - CVE-2014-7942: Uninitialized-value in Fonts.
    - CVE-2014-7943: Out-of-bounds read in Skia.
    - CVE-2014-7944: Out-of-bounds read in PDFium.
    - CVE-2014-7945: Out-of-bounds read in PDFium.
    - CVE-2014-7946: Out-of-bounds read in Fonts.
    - CVE-2014-7947: Out-of-bounds read in PDFium.
    - CVE-2014-7948: Caching error in AppCache.
  * debian/patch/search-credit: Don't force client in GOOG suggestions search.
    (LP: #1398900)
  * debian/patches/dri3-within-sandbox: Backport V41 sandbox, fixing DRI3.
    (LP: #1378627)
  * debian/patches/macro-templates-not-match: Remove. No longer necessary.
  * debian/patches/arm-neon.patch: Kill armv7=neon assumption. Fix typos.
  * debian/rules: chrpath for all packages. (LP: #1415555)
 -- Chad MILLER <email address hidden> Fri, 30 Jan 2015 15:48:09 -0500

Changed in chromium-browser (Ubuntu):
status: Fix Committed → Fix Released

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora 'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 20 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this

Thank you for reporting this bug and we are sorry it could not be fixed.

Changed in chromium-browser (Debian):
status: Confirmed → Fix Released
Changed in chromium-browser (Fedora):
importance: Unknown → Undecided
status: Unknown → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.