817514 - Fennec 19 crash in arm_neon_fill

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Scoobidiver (away)]

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

[Lukas Blakk [:lsblakk] use ?needinfo]

Kairo - is there any more information you can get from these crashes to indicate what the regression might be?

Comment 2

[Robert Kaiser]

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.

Comment 3

[Scoobidiver (away)]

(In reply to Robert Kaiser (:[e-mail]) 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.

Comment 4

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

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.

Comment 5

[Brad Lassey [:blassey] (use needinfo?)]

Kats, do you need any more info here?

Comment 6

[Kartikaya Gupta (email:[e-mail])]

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.

Comment 7

[Milan Sreckovic [:milan] (needinfo for best results)]

Benoit, there is a suggestion this is related to a bug you fixed in the past.

Comment 8

[Brad Lassey [:blassey] (use needinfo?)]

BenWa, do you have a plan here?

Comment 9

[Benoit Girard (:BenWa)]

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+?

Comment 10

[Benoit Girard (:BenWa)]

builddate* of 20121217+?

Comment 11

[Robert Kaiser]

(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?

Comment 12

[Scoobidiver (away)]

(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.

Comment 13

[Scoobidiver (away)]

Bug 817134 was uplifted to 19.0 Beta.