705277 - chromehang | epoll_wait in nsSVGTextPathElement::GetStartPositionOfChar

Status: RESOLVED WORKSFORME

(Core :: SVG, defect)

Description

[Cristian Nicolae (:xti)]

Attachment: crash log

Mozilla/5.0 (Android;Linux armv7l;rv:11.0a1)Gecko/20111125
Firefox/11.0a1 Fennec/11.0a1
Devices: Samsung Galaxy Nexus S
OS: Android 2.3.6


Possible steps to reproduce:
1. Open Fennec App
2. Go to about:config
3. Tap on Modify button for any preference from the list
4. Wait a couple of minutes

Expected result:
No crash occurs after step 4.

Actual result:
After step 4, the following crash occurs:
https://crash-stats.mozilla.com/report/index/bp-c8595829-8ead-43d5-b47a-d97272111125

Comment 1

[Aaron Train [:aaronmt]]

bp-c8595829-8ead-43d5-b47a-d97272111125

Comment 2

[Henrik Skupin [:whimboo][⌚️UTC+2]]

I hit the same crash today but during the start up of yesterdays nightly build:
bp-e2c80564-d709-4d0d-9a0a-326c22111125

0 	libmozalloc.so 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:66
1 	libc.so 	__swrite 	
2 	libxul.so 	libxul.so@0xee9051 	
3 	dalvik-heap (deleted) 	dalvik-heap @0x11f911f 	
4 	libxul.so 	nsSVGTextPathElement::GetStartPositionOfChar 	content/svg/content/src/nsSVGTextPathElement.h:71
5 		@0x3a646570 	
6 	libxul.so 	nsHtml5TreeOperation::Perform 	nsCOMPtr.h:509
7 		@0x48affda2 	
8 	libxul.so 	nsStringBuffer::Release 	xpcom/string/src/nsSubstring.cpp:188
9 	libxul.so 	ReleaseData 	xpcom/string/src/nsSubstring.cpp:118
10 	libxul.so 	nsACString_internal::Finalize 	xpcom/string/src/nsTSubstring.cpp:188
11 	libxul.so 	nsBaseHashtable<nsCStringHashKey, nsCString, nsCString>::s_EnumReadStub 	nsTSubstring.h:113
12 	libxul.so 	PL_DHashTableEnumerate 	obj-firefox/xpcom/build/pldhash.cpp:755
13 	libxul.so 	CrashReporter::AnnotateCrashReport 	nsTSubstring.h:113
14 	libxul.so 	mozilla::HangMonitor::Crash 	xpcom/threads/HangMonitor.cpp:111
15 	libxul.so 	mozilla::HangMonitor::ThreadMain 	xpcom/threads/HangMonitor.cpp:150
16 	libnspr4.so 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c:187
17 	libc.so 	__thread_entry 	
18 	libc.so 	pthread_create

Comment 3

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

On Nov 28, 9:28 am, JP Rosevear <[e-mail]> wrote:
> Please note that the hang monitor:https://bugzilla.mozilla.org/show_bug.cgi?id=429592
>
> Landed last week.  Reports tagged with "chromehang" in Soccorro are
> coming from this change.
>
> This spiked our crash data quite a bit (4-5x).
>
> There were a couple of problems when this landed, the first was that it
> didn't work on Mac as expected:https://bugzilla.mozilla.org/show_bug.cgi?id=705154
>
> The second was that plugin hangs were getting conflated with chrome
> hangs:https://bugzilla.mozilla.org/show_bug.cgi?id=705365
>
> These changes rolled out with the 11/26 nightly and the volume has
> reduced to 2-3x prior to that of 429592 landing.  As part of 705365 we
> dropped the plugin hang timer to 25s meaning we are probably getting
> more plugin hangs than before as well as the chromehangs.
>
> I think we can safely ignore the chromehang crash data from prior to the
> Nov 26 nightly build (sorting by install date in soccorro should be
> mostly right).  The hang monitor will likely be preffed off now will we
> analyze the data from the last couple of days for correctness of the
> hang monitor and from the hangs its thrown up - several of these appear
> to be very real.
>
> Further discussion can take place in bugs or at the 10am PST Crashkill
> meeting today.
>
> Thanks,
>
> -JP

Comment 4

[Scoobidiver (away)]

The stack trace in thread 0 is:
Frame 	Module 	Signature [Expand] 	Source
0 	libc.so 	epoll_wait 	
1 	libutils.so 	_ZN7android6Looper9pollInnerEi 	
2 	libutils.so 	_ZN7android6Looper8pollOnceEiPiS1_PPv 	
3 	libandroid_runtime.so 	_ZN7android18NativeMessageQueue8pollOnceEi 	
4 	libandroid_runtime.so 	_ZN7android18NativeMessageQueue8pollOnceEi 	
5 	libdvm.so 	dvmPlatformInvoke 	
6 	libdvm.so 	dvmCallJNIMethod_virtualNoRef 	
7 	dalvik-jit-code-cache (deleted) 	dalvik-jit-code-cache @0x23e 	
8 	libdvm.so 	dexDataMapAlloc 	
9 	libdvm.so 	dvmMterpStd 	
10 	libdvm.so 	dvmInterpret 	
11 	libdvm.so 	dvmInvokeMethod 	
12 	libdvm.so 	dvmFreeDexOrJar 	
13 	libdvm.so 	dvmAsmSisterStart 	
14 	libdvm.so 	dvmMterpStd 	
15 	libdvm.so 	dvmInterpret 	
16 	libdvm.so 	dvmCallMethodV 	
17 	libdvm.so 	JNI_CreateJavaVM 	
18 	libandroid_runtime.so 	_ZN7android14AndroidRuntime6onExitEi 	
19 	libandroid_runtime.so 	_ZN7android14AndroidRuntime5startEPKcb 	
20 	app_process 	app_process@0xccb 	
21 	app_process 	app_process@0x1026 	
22 	libandroid_runtime.so 	_ZN7android42register_android_content_res_ConfigurationEP7_JNIEnv 	
23 	app_process 	app_process@0xb32 	
24 	app_process 	app_process@0xb32 	
25 	libc.so 	__libc_init 	
26 		@0xffffffe2 	
27 	app_process 	app_process@0x32 	
28 	app_process 	app_process@0xb1e 	
29 	libxul.so 	nsIFrame::BuildDisplayListForChild 	layout/base/nsDisplayList.h:1198
30 		@0x6f77656b 	
31 	libxul.so 	CreateMarkerProperty 	mozalloc.h:228
32 		@0x662f6d63 	
33 	libxul.so 	nsSVGClipPathFrame::Init 	layout/generic/nsIFrame.h:1351
34 		@0x524f575d 	
35 	dalvik-heap (deleted) 	dalvik-heap @0x14fc349 	
36 	dalvik-heap (deleted) 	dalvik-heap @0xffa834 	
37 	org.mozilla.fennec-2.apk 	org.mozilla.fennec-2.apk@0x55f34d 

More crash reports at:
https://crash-stats.mozilla.com/report/list?signature=chromehang%20|%20epoll_wait

Comment 5

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

I don't see this exact crash signature ATM in socorro.  Closing out, reopen if this reappears.

Comment 6

[Scoobidiver (away)]

(In reply to Naoki Hirata :nhirata from comment #5)
> I don't see this exact crash signature ATM in socorro.
The hang detector has been disabled (pref set to 0) but that doesn't mean the hang cause is fixed.

Comment 7

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

Thank you for the comment; it was informative.

Perhaps I am missing something or I am wrong; I am uncertain what the value of keeping an unactionable crash that does not occur because the pref is turned off and the code path cannot be easily followed by an end user.  The exact signature would not be the same for the root cause if this is still possible with the pref turned off.  

If you can let me know the value of keeping this bug open, please let me know; otherwise I would suggest that we close this bug off as works for me until we have reproducible steps, or better clarity on the bug.  I cannot reproduce the issue with the steps provided.

Comment 8

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

Hrm.  I hit return a little too early.  I will try to turn on the pref; I forgot the pref was turned off when I tested.  If I cannot repro with the steps, then I will be closing the bug.

Comment 9

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

hangmonitor.timeout is turned to 1000.  The issue has not reproduced.

Comment 10

[Scoobidiver (away)]

(In reply to Naoki Hirata :nhirata from comment #9)
> hangmonitor.timeout is turned to 1000.
Before this value was set to 0, it was set to 30 (seconds) (see https://hg.mozilla.org/mozilla-central/rev/95bca70369ef), not 17 min.
Can you reproduce the crash with the original value?

Comment 11

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

Teaches me to look in hg first before assuming that it was set in milliseconds like some of the other timers.  Valid point, though I left the device along for more than 17 minutes while looking at other phones.  Retesting still shows the same; I cannot reproduce the issue.

Comment 12

[Scoobidiver (away)]

(In reply to Naoki Hirata :nhirata from comment #11)
> it was set in milliseconds like some of the other timers.
I guess that timers that can potentially exceed 65536 (or 32768) milliseconds are in second.