Closed Bug 738935 Opened 12 years ago Closed 12 years ago

OOM crash in nsWindow::DrawTo

Categories

(Core Graveyard :: Widget: Android, defect)

14 Branch
ARM
Android
defect
Not set
critical

Tracking

(blocking-fennec1.0 -)

RESOLVED DUPLICATE of bug 737928
Tracking Status
blocking-fennec1.0 --- -

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, reproducible, Whiteboard: [native-crash][startupcrash])

Crash Data

It might be related to bug 696804.

Signature 	TouchBadMemory | mozalloc_abort | moz_xmalloc | nsWindow::DrawTo More Reports Search
UUID	309e0c44-e801-421b-bfd2-f15812120323
Date Processed	2012-03-23 06:18:10
Uptime	1
Last Crash	2.3 hours before submission
Install Age	16.2 hours since version was first installed.
Install Time	2012-03-22 14:02:50
Product	FennecAndroid
Version	14.0a1
Build ID	20120322031220
Release Channel	nightly
OS	Linux
OS Version	0.0.0 Linux 2.6.32.9-perf #1 PREEMPT Tue Sep 20 13:35:04 2011 armv7l
Build Architecture	arm
Build Architecture Info	
Crash Reason	SIGSEGV
Crash Address	0x0
App Notes 	
EGL? EGL+ AdapterVendorID: semc, AdapterDeviceID: SO-02C.
AdapterDescription: 'Android, Model: 'SO-02C', Product: 'SO-02C_1249-5055', Manufacturer: 'Sony Ericsson', Hardware: 'semc''.
GL Context? GL Context+ GL Layers? GL Layers- 
Sony Ericsson SO-02C
docomo/SO-02C_1249-5055/SO-02C:2.3.4/4.0.1.C.1.9/9nv33w:user/release-keys
EMCheckCompatibility	True	
OOMAllocationSize	108

Frame 	Module 	Signature [Expand] 	Source
0 	libmozalloc.so 	TouchBadMemory 	memory/mozalloc/mozalloc_abort.cpp:68
1 	libmozalloc.so 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:89
2 	libmozalloc.so 	moz_xmalloc 	memory/mozalloc/mozalloc.cpp:105
3 	libxul.so 	nsWindow::DrawTo 	mozalloc.h:229
4 	libxul.so 	nsWindow::DrawTo 	widget/android/nsWindow.cpp:1106
5 	libxul.so 	nsWindow::OnDraw 	widget/android/nsWindow.cpp:1173
6 	libxul.so 	nsWindow::OnGlobalAndroidEvent 	widget/android/nsWindow.cpp:945
7 	libxul.so 	nsAppShell::ProcessNextNativeEvent 	widget/android/nsAppShell.cpp:571
8 	libxul.so 	nsBaseAppShell::DoProcessNextNativeEvent 	widget/xpwidgets/nsBaseAppShell.cpp:171
9 	libxul.so 	nsBaseAppShell::OnProcessNextEvent 	widget/xpwidgets/nsBaseAppShell.cpp:312
10 	libxul.so 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:619
11 	libxul.so 	NS_ProcessNextEvent_P 	obj-firefox/xpcom/build/nsThreadUtils.cpp:245
12 	libxul.so 	mozilla::ipc::MessagePump::Run 	ipc/glue/MessagePump.cpp:110
13 	libxul.so 	MessageLoop::RunInternal 	ipc/chromium/src/base/message_loop.cc:208
14 	libxul.so 	MessageLoop::Run 	ipc/chromium/src/base/message_loop.cc:201
15 	libxul.so 	nsBaseAppShell::Run 	widget/xpwidgets/nsBaseAppShell.cpp:189
16 	libxul.so 	nsAppStartup::Run 	toolkit/components/startup/nsAppStartup.cpp:295
17 	libxul.so 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3703
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=TouchBadMemory+|+mozalloc_abort+|+moz_xmalloc+|+nsWindow%3A%3ADrawTo
Depends on: 750051
It's #5 top crasher in 14.0a2 over the last 3 days. I don't know if every test cases are covered by bug 750051.
Keywords: topcrash
blocking-fennec1.0: --- → ?
Renom if this stays on the list
blocking-fennec1.0: ? → -
Another OOM bug that will be helped by fixing 748531.
Depends on: 748531
Whoops, got carried away. This one won't be helped by 748531 as it's not JNI-related, it's a gecko alloc fail.
No longer depends on: 748531
Number 15 on Aurora... but if the libdvm bugs are cleared out, then it's within the top 10.  (#7 excluding libdvm crashes)
blocking-fennec1.0: - → ?
Waiting for better STR
Keywords: qawanted
blocking-fennec1.0: ? → -
devices:
Sony Ericsson R800i
Sony Ericsson MT11i
LGE VS910 4G
Sony Ericsson ST18i
HTC Vision
HTC ADR6300
HTC Desire S
HTC Evo
HTC Nexus One
Droid 3
Motorola MB865
Samsung Galaxy S II

url:
about:blank
about:home
Summary: crash in nsWindow::DrawTo @ TouchBadMemory → OOM crash in nsWindow::DrawTo
I am always able to reproduce this crash on the latest Nightly on a clean profile by following these steps:

1. Open Fennec
2. Open the following pages, each one in a new tab: yahoo.com, cnn.com, news.google.com, planet.mozilla.org
3. Open a new tab and go to https://adblockplus.org/devbuilds/adblockplus/adblockplus-2.0.4a.3399.xpi (http://goo.gl/jOSYR) and install the add-on
4. When install is complete, a popup is triggered. Tap on Restart button
5. After Fennec restarts, wait

Actual result:
https://crash-stats.mozilla.com/report/index/bp-085ef5d9-d981-4b3e-837a-33d202120521

--
Firefox 15.0a1 (2012-05-20)
Device: Samsung Captivate
OS: Android 2.2
Now that bug 750051 is fixed, it's only #35 top crasher in 14.0b2.
Nevertheless, as it implies ABP, I think it should be a blocker for native Fennec.
blocking-fennec1.0: - → ?
I can also reproduce with the str in comment 8, using the Galaxy Nexus on trunk.
We need to test that this is related directly to ABP or just any add-on that requires a restart. Can we make that determination?
Keywords: qawanted
There's an ABP-related crash in bug 737928 that looks like random memory corruption, just like this one; it might be related.
I think the crash is being caused by a restart by addon + restore tabs + redirect to a chrome:// page on the active tab.

1) I tried with mfinkle's restarting addon, but that did not cause the crash.
ABP did cause the same crash signature to appear.

2) What I do recall of ABP is that it tried to change the page to a chrome:// page on first restart.
Though, I came to realize, restart addon is restartless after installation.

We should probably check with an addon that causes restart after installation just to be sure.
(In reply to Naoki Hirata :nhirata from comment #14)
> Though, I came to realize, restart addon is restartless after installation.
> 
> We should probably check with an addon that causes restart after
> installation just to be sure.

This add-on will cause a retstart:
https://addons.mozilla.org/en-US/android/addon/copy-as-plain-text
It doesn't seem to be the restart in itself.  The restart from the addon will restart fennec. the latest nightly (5/29/2012) will not restore the tabs, it will open to about:home after restart.  I think it may have to do with the redirect to a chrome page.  

Probably should try to reduce the original addon.
After talking to kbrosnan, the main requirement was to check if all restart addons were causing the issue or just ABP.  It looks like it's just ABP.  (possibly the redirect to a chrome: page).  Removing qawanted.
Keywords: qawanted
Status: NEW → RESOLVED
blocking-fennec1.0: ? → -
Closed: 12 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.