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).
Another one: bp-52b6adac-1eab-44d8-9f1b-46b012150826
Benwa, does this crash signature look familiar to you?
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.
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
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.