Closed
Bug 817514
Opened 13 years ago
Closed 13 years ago
Fennec 19 crash in arm_neon_fill
Categories
(Core :: Graphics, defect)
Tracking
()
RESOLVED
FIXED
mozilla20
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
Comment 1•13 years ago
|
||
Kairo - is there any more information you can get from these crashes to indicate what the regression might be?
tracking-firefox20:
--- → +
Reporter | ||
Updated•13 years ago
|
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]
![]() |
||
Comment 2•13 years ago
|
||
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…
Reporter | ||
Comment 3•13 years ago
|
||
(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.
Updated•13 years ago
|
Assignee: nobody → bugmail.mozilla
tracking-fennec: ? → 19+
a couple of urls:
http://www.fanfiction.net/s/7665729/31/
http://www.neogaf.com/forum/showthread.php?t=503356
We have had arm_neon_fill bugs before :
https://bugzilla.mozilla.org/buglist.cgi?list_id=5180593;short_desc=arm_neon_fill;classification=Client%20Software;classification=Components;query_format=advanced;bug_status=UNCONFIRMED;bug_status=NEW;bug_status=READY;bug_status=ASSIGNED;bug_status=REOPENED;bug_status=RESOLVED;bug_status=VERIFIED;short_desc_type=allwordssubstr;product=Core;product=Fennec;product=Firefox%20for%20Android
I don't see a strong correlation between versions and graphics card yet : 4.2.1, 4.0.4.
Reporter | ||
Updated•13 years ago
|
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…
Reporter | ||
Updated•13 years ago
|
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…
Comment 6•13 years ago
|
||
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)
Comment 7•13 years ago
|
||
Benoit, there is a suggestion this is related to a bug you fixed in the past.
Assignee: bugmail.mozilla → bgirard
Assignee | ||
Comment 9•13 years ago
|
||
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)
Assignee | ||
Comment 10•13 years ago
|
||
builddate* of 20121217+?
![]() |
||
Comment 11•13 years ago
|
||
(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?
Reporter | ||
Comment 12•13 years ago
|
||
(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
Reporter | ||
Comment 13•13 years ago
|
||
Bug 817134 was uplifted to 19.0 Beta.
Reporter | ||
Updated•13 years ago
|
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]
You need to log in
before you can comment on or make changes to this bug.
Description
•