Closed Bug 1248945 Opened 9 years ago Closed 9 years ago

Intermittent 795892-1.html | application crashed [None]

Categories

(Core :: General, defect)

Product:
Core
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1239162
Tracking Flags:
Tracking Status
firefox47 --- affected

People

(Reporter: cbook, Unassigned)

References

(
URL
)

Details

(Keywords: intermittent-failure)

Maire, it looks like this media test just started failing frequently within the last day or so. Any thoughts on what caused it or who could work it? Thanks!
Flags: needinfo?(mreavy)
Paul -- Can you tell me if this is crash is in cubeb or elsewhere -- e.g. in Playback? The relevant test is this one: dom/media/test/crashtests/795892-1.html Thanks.
Flags: needinfo?(mreavy) → needinfo?(padenot)
Nope, I can't, there is nothing in the log, the minidump stack walking did not work. I could not find a occurrence of this with decoded stacks, clicking through multiple failures on brassstack.
Flags: needinfo?(padenot)
(In reply to Ben Kelly [:bkelly] from comment #2) > Maire, it looks like this media test just started failing frequently within > the last day or so. Any thoughts on what caused it or who could work it? dom/media/test/crashtests/795892-1.html was just updated in bug 1248543. https://hg.mozilla.org/integration/mozilla-inbound/rev/0d9af8eaf17f didn't trigger Android crashtests, but it looks like the cause. jwwang - can you have a look? This is failing frequently.
Flags: needinfo?(jwwang)
Scrolling down a bit in the log I see: Fatal signal 11 (SIGSEGV) at 0xe5e5e5e5 (code=1), thread 1149 (Compositor) That's a bit worrying since it indicates a use-after-free. I can't tell if that's the original crash reason though.
It is very easy to repro on Android 4.3 API15+ debug. Try: https://treeherder.mozilla.org/logviewer.html#?job_id=17016048&repo=try With the symbols (http://archive.mozilla.org/pub/mobile/try-builds/jwwang@mozilla.com-12efe31b9333414fc9796a90ff7171c46aa71642/try-android-api-15-debug/) I am able to decode the backtrace: 00992fcf FUNC 992f1c 114 0 mozilla::gl::AndroidSurfaceTexture::~AndroidSurfaceTexture 00a07347 FUNC a072f4 90 0 mozilla::layers::AndroidSurfaceTextureData::~AndroidSurfaceTextureData 00a07389 FUNC a07384 12 0 mozilla::layers::AndroidSurfaceTextureData::~AndroidSurfaceTextureData 009d9631 FUNC 9d9598 a8 0 mozilla::layers::DestroyTextureData 009da1c3 FUNC 9da0d8 35c 0 mozilla::layers::DeallocateTextureClient 009da583 FUNC 9da494 118 0 mozilla::layers::TextureClient::Destroy 009da5bd FUNC 9da5ac d8 0 mozilla::layers::TextureClient::~TextureClient 009da689 FUNC 9da684 12 0 mozilla::layers::TextureClient::~TextureClient 00990bbf FUNC 990aa0 1e4 0 mozilla::AtomicRefCountedWithFinalize<mozilla::layers::TextureClient>::Release 00990c8f FUNC 990c84 12 0 RefPtr<mozilla::layers::TextureClient>::~RefPtr 009d7e8f FUNC 9d7e28 c0 0 nsTArray_Impl<mozilla::layers::ImageClientSingle::Buffer, nsTArrayInfallibleAllocator>::RemoveElementsAt 009fd703 FUNC 9fd6b0 ac 0 mozilla::layers::FlushAllImagesSync 005b6023 FUNC 5b5ff0 4c 0 MessageLoop::RunTask I think the change of bug 1248543 reveals a bug of gfx.
Flags: needinfo?(jwwang)
It looks the same issue of bug 1239162. Hi Peter, Can you confirm if bug 1239162 fix the problem here? step to repro: Run crashtests on Android with |./mach try -b do -p android-api-15 -u reftest -t none|
Flags: needinfo?(howareyou322)
(In reply to JW Wang [:jwwang] from comment #9) > It is very easy to repro on Android 4.3 API15+ debug. Try: > https://treeherder.mozilla.org/logviewer.html#?job_id=17016048&repo=try > > With the symbols > (http://archive.mozilla.org/pub/mobile/try-builds/jwwang@mozilla.com- > 12efe31b9333414fc9796a90ff7171c46aa71642/try-android-api-15-debug/) I am > able to decode the backtrace: > > 00992fcf FUNC 992f1c 114 0 > mozilla::gl::AndroidSurfaceTexture::~AndroidSurfaceTexture > 00a07347 FUNC a072f4 90 0 > mozilla::layers::AndroidSurfaceTextureData::~AndroidSurfaceTextureData > 00a07389 FUNC a07384 12 0 > mozilla::layers::AndroidSurfaceTextureData::~AndroidSurfaceTextureData > 009d9631 FUNC 9d9598 a8 0 mozilla::layers::DestroyTextureData > 009da1c3 FUNC 9da0d8 35c 0 mozilla::layers::DeallocateTextureClient > 009da583 FUNC 9da494 118 0 mozilla::layers::TextureClient::Destroy > 009da5bd FUNC 9da5ac d8 0 mozilla::layers::TextureClient::~TextureClient > 009da689 FUNC 9da684 12 0 mozilla::layers::TextureClient::~TextureClient > 00990bbf FUNC 990aa0 1e4 0 > mozilla::AtomicRefCountedWithFinalize<mozilla::layers::TextureClient>:: > Release > 00990c8f FUNC 990c84 12 0 RefPtr<mozilla::layers::TextureClient>::~RefPtr > 009d7e8f FUNC 9d7e28 c0 0 > nsTArray_Impl<mozilla::layers::ImageClientSingle::Buffer, > nsTArrayInfallibleAllocator>::RemoveElementsAt > 009fd703 FUNC 9fd6b0 ac 0 mozilla::layers::FlushAllImagesSync > 005b6023 FUNC 5b5ff0 4c 0 MessageLoop::RunTask > > I think the change of bug 1248543 reveals a bug of gfx. The patch of bug 1239162 was trying to fix use-after-free in server side(compositor). It is related but I'm not sure it helps or not. Trigger another try to check the reproduce rate. https://treeherder.mozilla.org/#/jobs?repo=try&revision=5c151afb00e1
Flags: needinfo?(howareyou322)
I triggered several Android crashtests on https://treeherder.mozilla.org/#/jobs?repo=try&revision=5c151afb00e1 -- all green!
(In reply to Geoff Brown [:gbrown] from comment #12) > I triggered several Android crashtests on > https://treeherder.mozilla.org/#/jobs?repo=try&revision=5c151afb00e1 -- all > green! Wow, that's good news for me. I will mark this as duplicate of but 1239162
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.