Closed Bug 817514 Opened 13 years ago Closed 13 years ago

Fennec 19 crash in arm_neon_fill

Categories

(Core :: Graphics, defect)

19 Branch
ARM
Android
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla20
Tracking Status
firefox18 --- unaffected
firefox19 + fixed
firefox20 + fixed
fennec 19+ ---

People

(Reporter: scoobidiver, Assigned: BenWa)

References

Details

(Keywords: crash, regression, topcrash)

Crash Data

It's similar to bug 795234 but this time it spiked in Fennec 19. It's indeed #5 top crasher in 19.0a2 and #3 in 20.0a1 with combined signatures. Signature libxul.so@0xca48e8 | arm_neon_fill More Reports Search UUID 455f2355-c1e8-454f-8c1b-fa3112121203 Date Processed 2012-12-03 07:48:21 Uptime 2204 Install Age 2.7 hours since version was first installed. Install Time 2012-12-03 00:01:00 Product FennecAndroid Version 20.0a1 Build ID 20121202030723 Release Channel nightly OS Android OS Version 0.0.0 Linux 3.0.31-gd5a18e0 #1 SMP PREEMPT Fri Nov 2 11:02:59 PDT 2012 armv7l google/yakju/maguro:4.2.1/JOP40D/533553:user/release-keys Build Architecture arm Build Architecture Info Crash Reason SIGSEGV Crash Address 0x64100000 App Notes AdapterDescription: 'Imagination Technologies -- PowerVR SGX 540 -- OpenGL ES 2.0 build 1.8@905891 -- Model: Galaxy Nexus, Product: yakju, Manufacturer: samsung, Hardware: tuna' EGL? EGL+ GL Context? GL Context+ GL Layers? GL Layers+ samsung Galaxy Nexus google/yakju/maguro:4.2.1/JOP40D/533553:user/release-keys Processor Notes /data/socorro/stackwalk/bin/exploitable: ERROR: unable to analyze dump EMCheckCompatibility True Adapter Vendor ID Imagination Technologies Adapter Device ID PowerVR SGX 540 Device samsung Galaxy Nexus Android API Version 17 (REL) Android CPU ABI armeabi-v7a Frame Module Signature Source 0 libxul.so libxul.so@0xca48e8 1 libxul.so arm_neon_fill pixman-arm-neon.c:226 2 libxul.so _pixman_implementation_fill pixman-implementation.c:182 3 libxul.so delegate_fill pixman-implementation.c:62 4 libxul.so _pixman_implementation_fill pixman-implementation.c:182 5 libxul.so _moz_pixman_fill pixman.c:772 6 libxul.so _clip_and_composite_boxes cairo-image-surface.c:2940 7 libxul.so _cairo_image_surface_paint cairo-image-surface.c:3282 8 libxul.so _cairo_surface_paint cairo-surface.c:2109 9 libxul.so _cairo_gstate_fill cairo-gstate.c:1285 10 libxul.so _moz_cairo_fill_preserve cairo.c:2459 11 libxul.so gfxContext::Fill gfxContext.cpp:310 12 libxul.so nsRenderingContext::FillRect nsRenderingContext.cpp:332 13 libxul.so nsDisplayCanvasBackground::Paint nsCanvasFrame.cpp:200 14 libxul.so mozilla::FrameLayerBuilder::DrawThebesLayer FrameLayerBuilder.cpp:3282 15 libxul.so mozilla::layers::BasicThebesLayer::PaintThebes BasicThebesLayer.cpp:139 16 libxul.so mozilla::layers::BasicLayerManager::PaintSelfOrChildren BasicLayerManager.cpp:829 17 libxul.so mozilla::layers::BasicLayerManager::PaintLayer BasicLayerManager.cpp:954 18 libxul.so mozilla::layers::BasicLayerManager::PaintSelfOrChildren BasicLayerManager.cpp:844 19 libxul.so mozilla::layers::BasicLayerManager::PaintLayer BasicLayerManager.cpp:954 20 libxul.so mozilla::layers::BasicLayerManager::EndTransactionInternal BasicLayerManager.cpp:593 21 libxul.so mozilla::layers::BasicLayerManager::EndTransaction BasicLayerManager.cpp:508 22 libxul.so nsDisplayList::PaintForFrame const nsDisplayList.cpp:1142 23 libxul.so nsDisplayList::PaintRoot const nsDisplayList.cpp:1003 24 libxul.so nsLayoutUtils::PaintFrame nsLayoutUtils.cpp:1872 25 libxul.so PresShell::RenderDocument nsPresShell.cpp:4388 26 libxul.so mozilla::AndroidBridge::TakeScreenshot AndroidBridge.cpp:2567 27 libxul.so ScreenshotRunnable::Run nsAppShell.cpp:92 28 libxul.so RunnableMethod<ScreenshotRunnable, tag_nsresult tuple.h:383 29 libxul.so MessageLoop::RunTask message_loop.cc:333 ... More reports at: https://crash-stats.mozilla.com/query/query?product=FennecAndroid&version=FennecAndroid%3A20.0a1&version=FennecAndroid%3A19.0a2&query_search=signature&query_type=contains&query=arm_neon_fill&reason=&do_query=1
Kairo - is there any more information you can get from these crashes to indicate what the regression might be?
Crash Signature: libxul.so@0xc984e0 | arm_neon_fill] [@ libxul.so@0xca48e8 | arm_neon_fill] [@ libxul.so@0xc9a8a8 | arm_neon_fill] → libxul.so@0xc984e0 | arm_neon_fill] [@ libxul.so@0xca48e8 | arm_neon_fill] [@ libxul.so@0xc9a8a8 | arm_neon_fill] [@ libxul.so@0xc99568 | arm_neon_fill] [@ libxul.so@0xca6268 | arm_neon_fill] [@ libxul.so@0xcaed68 | arm_neon_fill]
Naoki, Kevin, I remember we had arm_neon_fill problem before, can you help here? In any case, it's not a regression, https://crash-stats.mozilla.com/report/list?signature=libxul.so%400xc920c8%20|%20arm_neon_fill is 18.0b2, and https://crash-stats.mozilla.com/report/list?signature=libxul.so%400xc36758%20|%20arm_neon_fill is 17.0, I saw a 16.0.2 variant around as well when searching for this. I took a fast look through the device reports, and I think most of what I saw look like Tegra systems, probably tegra3, but Naoki or Kevin can give you more info there, they know the scene much better than me.
Crash Signature: libxul.so@0xc984e0 | arm_neon_fill] [@ libxul.so@0xca48e8 | arm_neon_fill] [@ libxul.so@0xc9a8a8 | arm_neon_fill] [@ libxul.so@0xc99568 | arm_neon_fill] [@ libxul.so@0xca6268 | arm_neon_fill] [@ libxul.so@0xcaed68 | arm_neon_fill] → libxul.so@0xc984e0 | arm_neon_fill] [@ libxul.so@0xca48e8 | arm_neon_fill] [@ libxul.so@0xc9a8a8 | arm_neon_fill] [@ libxul.so@0xc99568 | arm_neon_fill] [@ libxul.so@0xca6268 | arm_neon_fill] [@ libxul.so@0xcaed68 | arm_neon_fill] [@ libxul.so@0xc36…
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #2) > In any case, it's not a regression. It's #351 top crasher in 17.0, #130 in 18.0b2, #5 in 19.0a2 and #7 in 20.0a1 so it's clearly a regression in 19.0. Previous crashes were tracked in bug 711852. They are residual crashes not fixed by bug 805355 so the regression range is in bug 805355 comment 0.
Assignee: nobody → bugmail.mozilla
tracking-fennec: ? → 19+
Keywords: qawanted
QA Contact: kbrosnan
Crash Signature: libxul.so@0xc36758 | arm_neon_fill] [@ libxul.so@0xc920c8 | arm_neon_fill] → libxul.so@0xc36758 | arm_neon_fill] [@ libxul.so@0xc920c8 | arm_neon_fill] [@ libxul.so@0xc9d968 | arm_neon_fill] [@ libxul.so@0xcbe828 | arm_neon_fill] [@ libxul.so@0xc9d5e8 | arm_neon_fill] [@ libxul.so@0xc9d928 | arm_neon_fill] [@ libxul.so@0xcb1…
Crash Signature: [@ libxul.so@0xc98b18 | arm_neon_fill] [@ libxul.so@0xc98e98 | arm_neon_fill] [@ libxul.so@0xc99428 | arm_neon_fill] [@ libxul.so@0xc99468 | arm_neon_fill] [@ libxul.so@0xc993a8 | arm_neon_fill] [@ libxul.so@0xc9a6e8 | arm_neon_fill] [@ libxul.so@0… → [@ fast_path_fill ] [@ libxul.so@0xc98b18 | arm_neon_fill] [@ libxul.so@0xc98e98 | arm_neon_fill] [@ libxul.so@0xc99428 | arm_neon_fill] [@ libxul.so@0xc99468 | arm_neon_fill] [@ libxul.so@0xc993a8 | arm_neon_fill] [@ libxul.so@0xc9a6e8 | arm_neon…
Kats, do you need any more info here?
Flags: needinfo?(bugmail.mozilla)
This would probably be better handled by the graphics team; they were the ones that fixed previous crashes in pixman and I don't know that code very well at all.
Flags: needinfo?(bugmail.mozilla)
Benoit, there is a suggestion this is related to a bug you fixed in the past.
Assignee: bugmail.mozilla → bgirard
BenWa, do you have a plan here?
Flags: needinfo?(bgirard)
Every time we run into this the surface we were drawing into wasn't valid. Something upstream passes a bad pointer and arm_neon_fill crashes. I believe we hit this once when we were drawing to a gralloc surface. I'd imagine that the memory block backing our screenshot is either invalid or too small. We crash on arm_neon_fill since it's the first piece of code that touches the screenshot destination memory block. I'd imagine that we would get this crash under a different signature for non neon device. I see that the screenshot code got deleted in bug 817134. Can we find this crash with install time of 20121217+?
Flags: needinfo?(bgirard)
builddate* of 20121217+?
(In reply to Benoit Girard (:BenWa) from comment #9) > I see that the screenshot code got deleted in bug 817134. Can we find this > crash with install time of 20121217+? Almost all crashes in the query of comment #0 are after that build date - but they are all on Aurora 19, not on Nightly 20. Does that mean that bug 817134 should be uplifted to 19?
(In reply to Benoit Girard (:BenWa) from comment #9) > I see that the screenshot code got deleted in bug 817134. Can we find this > crash with install time of 20121217+? The latest crashes happened in 20.0a1/20121215 so I assume bug 817134 has fixed it.
Status: NEW → RESOLVED
Closed: 13 years ago
Depends on: 817134
Resolution: --- → FIXED
Target Milestone: --- → mozilla20
Bug 817134 was uplifted to 19.0 Beta.
Crash Signature: arm_neon_fill] [@ libxul.so@0xcb1aa8 | arm_neon_fill] [@ libxul.so@0xcbe868 | arm_neon_fill] → arm_neon_fill] [@ libxul.so@0xcb1aa8 | arm_neon_fill] [@ libxul.so@0xcbe868 | arm_neon_fill] [@ libxul.so@0xc85f5c | arm_neon_fill]
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.