Closed Bug 1198869 Opened 9 years ago Closed 8 years ago

crash in i965_dri.so@0x39d4ac

Categories

(Core :: Graphics: Layers, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox43 --- affected

People

(Reporter: johnp, Unassigned)

References

Details

(Keywords: crash, Whiteboard: gfx-noted)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-eb196f02-3f40-43f3-bdf5-98f2b2150826.
=============================================================

Not much to say. No STR, all experimental layers features enabled (that I know of).
Benwa, does this crash signature look familiar to you?
Flags: needinfo?(bgirard)
Whiteboard: gfx-noted
This is Linux with OpenGL compositor, right?
Nope, but a crash in glClear sounds vaguely familiar. I can't recall if it was OSX or Linux. Andrew?
Flags: needinfo?(bgirard) → needinfo?(acomminos)
I think you might be thinking of the Talos regression we get with glClear on Mac. This crash seems like it might be caused by some rendering commands that get flushed when glClear gets called, not the clear itself.

It would be interesting to see if we can reproduce and get output with MOZ_GL_DEBUG_VERBOSE enabled.
Flags: needinfo?(acomminos)
Fedora 22 KDE KWin with OpenGL 3.3 on an Intel HD2000 iirc.
I'll try to reproduce with MOZ_GL_DEBUG_VERBOSE when I'm back at my desktop. Got a vague idea which websites could have triggered it last time. I assume a debug build is necessary?
No luck trying to reproduce deliberately, but just randomly crashed again in nightly:

bp-5065366c-559d-49c2-a870-151c02150830

I'd happily run debug all day, but that's unfortunately startup-crashing with an assertion-failure (!mAsyncExecutionThread (AsyncClose has not been invoked on this connection!)).
Mass resolving WFM: signature(s) hasn't(/haven't) reported in past 28 days.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.