Closed
Bug 705277
Opened 13 years ago
Closed 12 years ago
chromehang | epoll_wait in nsSVGTextPathElement::GetStartPositionOfChar
Categories
(Core :: SVG, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: xti, Unassigned)
References
Details
(Keywords: hang, Whiteboard: [native-crash])
Crash Data
Attachments
(1 file)
56.69 KB,
text/plain
|
Details |
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•13 years ago
|
||
bp-c8595829-8ead-43d5-b47a-d97272111125
Keywords: crash
Whiteboard: [native-crash]
Comment 2•13 years ago
|
||
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
On Nov 28, 9:28 am, JP Rosevear <j...@mozilla.com> 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
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
Comment 4•13 years ago
|
||
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
Updated•12 years ago
|
Summary: Crash [@ chromehang | epoll_wait ] → chromehang | epoll_wait in nsSVGTextPathElement::GetStartPositionOfChar
I don't see this exact crash signature ATM in socorro. Closing out, reopen if this reappears.
Status: REOPENED → RESOLVED
Closed: 13 years ago → 12 years ago
Resolution: --- → WORKSFORME
Comment 6•12 years ago
|
||
(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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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.
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.
hangmonitor.timeout is turned to 1000. The issue has not reproduced.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 12 years ago
Resolution: --- → WORKSFORME
Comment 10•12 years ago
|
||
(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?
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•12 years ago
|
||
(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.
You need to log in
before you can comment on or make changes to this bug.
Description
•