Closed Bug 694992 Opened 13 years ago Closed 13 years ago

Crash in mozilla::AndroidBridge::GetMimeTypeFromExtensions

Categories

(Core Graveyard :: Widget: Android, defect)

ARM
Android
defect
Not set
critical

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 748531

People

(Reporter: martijn.martijn, Assigned: blassey)

References

()

Details

(Keywords: crash, Whiteboard: [mobile-crash], [native-crash])

Crash Data

This bug was filed from the Socorro interface and is report bp-5e134001-3829-48b6-8c46-616df2111017 . ============================================================= 0 libdvm.so dvmStringLen 1 libdvm.so JNI_CreateJavaVM 2 libxul.so mozilla::nsJNIString::nsJNIString jni.h:834 3 libxul.so mozilla::AndroidBridge::GetMimeTypeFromExtensions nsTSubstring.h:594 4 libxul.so nsMIMEInfoAndroid::GetMimeInfoForFileExt nsTSubstring.h:594 5 libxul.so nsOSHelperAppService::GetMIMEInfoFromOS uriloader/exthandler/android/nsOSHelperAppService.cpp:64 6 libxul.so nsExternalHelperAppService::GetTypeFromExtension nsCOMPtr.h:473 7 libxul.so nsExternalHelperAppService::GetTypeFromFile uriloader/exthandler/nsExternalHelperAppService.cpp:2753 8 libxul.so nsFileChannel::MakeFileInputStream nsCOMPtr.h:522 9 libxul.so nsFileChannel::OpenContentStream netwerk/protocol/file/nsFileChannel.cpp:371 10 libxul.so nsBaseChannel::BeginPumpingData netwerk/base/src/nsBaseChannel.cpp:241 11 libxul.so nsBaseChannel::AsyncOpen netwerk/base/src/nsBaseChannel.cpp:610 12 libxul.so nsObjectLoadingContent::LoadObject content/base/src/nsObjectLoadingContent.cpp:1474 13 libxul.so nsObjectLoadingContent::LoadObject content/base/src/nsObjectLoadingContent.cpp:1144 14 libxul.so nsHTMLObjectElement::StartObjectLoad content/html/content/src/nsHTMLObjectElement.cpp:514 15 libxul.so nsHTMLObjectElement::DoneAddingChildren content/html/content/src/nsHTMLObjectElement.cpp:197 16 libxul.so nsHtml5TreeOperation::Perform parser/html/nsHtml5TreeOperation.cpp:623 17 libxul.so nsHtml5TreeOpExecutor::RunFlushLoop parser/html/nsHtml5TreeOpExecutor.cpp:534 18 libxul.so nsHtml5ExecutorFlusher::Run parser/html/nsHtml5StreamParser.cpp:158 19 libxul.so nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:631 20 libxul.so NS_ProcessNextEvent_P obj-firefox/xpcom/build/nsThreadUtils.cpp:245 Seeing this crash while testing trunk Fennec on the LG Optimus Black, on 2.2.2.
Here is an unminimized testcase: http://people.mozilla.com/~mwargers/tests/dvmstringlength/crash1.htm Actually, I'm more hitting these kind of crashes: https://crash-stats.mozilla.com/report/index/bp-124534d3-b386-488b-8b65-7dc742111017 0 libmozalloc.so mozalloc_abort memory/mozalloc/mozalloc_abort.cpp:66 1 libc.so __swrite 2 @0x3e 3 libc.so dlfree 4 libc.so dlfree 5 @0xbeb3341f 6 libmozutils.so Java_org_mozilla_gecko_GeckoAppShell_reportJavaCrash other-licenses/android/APKOpen.cpp:241 7 libdvm.so dvmPlatformInvoke 8 libdvm.so dvmCallJNIMethod_general 9 libdvm.so dvmResolveNativeMethod 10 libdvm.so dvmAsmSisterStart 11 libdvm.so dvmMterpStd 12 libdvm.so dvmInterpret 13 libdvm.so dvmInvokeMethod 14 libdvm.so dvmFreeDexOrJar 15 libdvm.so dvmAsmSisterStart 16 libdvm.so dvmMterpStd 17 libdvm.so dvmInterpret 18 libdvm.so dvmCallMethodV 19 libdvm.so JNI_CreateJavaVM 20 libandroid_runtime.so _ZN7android14AndroidRuntime6onExitEi 21 libandroid_runtime.so _ZN7android14AndroidRuntime5startEPKcb 22 app_process app_process@0xcaa 23 app_process app_process@0x1027 24 libandroid_runtime.so BTL_IFC_ClientInit 25 libc.so __libc_init
Also hit this crash once with the unminimized testcase, when tapping on the flash plugin placeholder: https://crash-stats.mozilla.com/report/index/bp-6369f3ee-7cc7-4e4f-92b8-769622111017 0 libxul.so nsPluginInstanceOwner::ProcessEvent nsRuleNode.h:680 1 libxul.so nsPluginInstanceOwner::DispatchMouseToPlugin dom/plugins/base/nsPluginInstanceOwner.cpp:1880 2 libxul.so nsPluginInstanceOwner::HandleEvent dom/plugins/base/nsPluginInstanceOwner.cpp:1924 3 libxul.so nsEventListenerManager::HandleEventSubType content/events/src/nsEventListenerManager.cpp:745 4 libxul.so nsEventListenerManager::HandleEventInternal content/events/src/nsEventListenerManager.cpp:795 5 libxul.so nsEventTargetChainItem::HandleEvent content/events/src/nsEventListenerManager.h:160 6 libxul.so nsEventTargetChainItem::HandleEventTargetChain content/events/src/nsEventDispatcher.cpp:346 7 libxul.so nsEventDispatcher::Dispatch content/events/src/nsEventDispatcher.cpp:674 8 libxul.so nsEventStateManager::DispatchMouseEvent content/events/src/nsEventStateManager.cpp:3839 9 libxul.so nsEventStateManager::NotifyMouseOut layout/generic/nsIFrame.h:3028 10 libxul.so nsEventStateManager::NotifyMouseOut content/events/src/nsEventStateManager.cpp:3918 11 libxul.so nsEventStateManager::NotifyMouseOver nsCOMPtr.h:693 12 libxul.so nsEventStateManager::GenerateMouseEnterExit nsCOMPtr.h:522 13 libxul.so nsEventStateManager::PreHandleEvent content/events/src/nsEventStateManager.cpp:1150 14 libxul.so PresShell::HandleEventInternal layout/base/nsPresShell.cpp:6358 15 libxul.so PresShell::HandlePositionedEvent layout/base/nsPresShell.cpp:6161 16 libxul.so PresShell::HandleEvent layout/base/nsPresShell.cpp:5996 17 libxul.so nsViewManager::HandleEvent view/src/nsViewManager.cpp:1027 18 libxul.so nsViewManager::DispatchEvent view/src/nsViewManager.cpp:1002 19 libxul.so HandleEvent nsCOMPtr.h:522 20 libxul.so nsWindow::DispatchEvent widget/src/android/nsWindow.cpp:631 etc..
Should we separate these crashes? Even though it comes from the same test case, it looks like they are separate crashes? Or did they happen all at the same time?
Whiteboard: [mobile-crash]
I don't know, at this point it's not important anymore, I guess, with the move to birch Fennec.
There is one crash in 11.a1/20111211: bp-f45c8ee3-9163-4e61-940a-c5d852111211
Crash Signature: [@ dvmStringLen] → [@ dvmStringLen] [@ dvmStringLen | JNI_CreateJavaVM | mozilla::nsJNIString::nsJNIString]
OS: Windows 7 → Android
Hardware: x86 → ARM
Summary: Crash [@ dvmStringLen] → Crash [@ dvmStringLen | JNI_CreateJavaVM | mozilla::nsJNIString::nsJNIString]
Depends on: 700463
Ok, I just crashed with Native Fennec too: https://crash-stats.mozilla.com/report/index/bp-c0c5339d-2510-42b7-83c4-49b692120111 0 libdvm.so dvmStringLen 1 libdvm.so JNI_CreateJavaVM 2 libxul.so mozilla::nsJNIString::nsJNIString jni.h:834 3 libxul.so mozilla::AndroidBridge::GetMimeTypeFromExtensions widget/android/AndroidBridge.cpp:512 4 libxul.so nsMIMEInfoAndroid::GetMimeInfoForFileExt uriloader/exthandler/android/nsMIMEInfoAndroid.cpp:113 5 libxul.so nsOSHelperAppService::GetMIMEInfoFromOS uriloader/exthandler/android/nsOSHelperAppService.cpp:64 6 libxul.so nsExternalHelperAppService::GetTypeFromExtension uriloader/exthandler/nsExternalHelperAppService.cpp:2613 7 libxul.so nsExternalHelperAppService::GetTypeFromFile uriloader/exthandler/nsExternalHelperAppService.cpp:2752 8 libxul.so nsFileChannel::MakeFileInputStream netwerk/protocol/file/nsFileChannel.cpp:301 9 libxul.so nsFileChannel::OpenContentStream netwerk/protocol/file/nsFileChannel.cpp:370 10 libxul.so nsBaseChannel::BeginPumpingData netwerk/base/src/nsBaseChannel.cpp:240 11 libxul.so nsBaseChannel::AsyncOpen netwerk/base/src/nsBaseChannel.cpp:609 12 libxul.so nsPluginHost::NewEmbeddedPluginStream dom/plugins/base/nsPluginHost.cpp:3313 13 libxul.so nsPluginHost::InstantiateEmbeddedPlugin dom/plugins/base/nsPluginHost.cpp:1097 etc...
Whiteboard: [mobile-crash] → [mobile-crash], [native-crash]
Martijn do you still reproduce this? Or did the click to play make a difference?
Currently, when the flash plugin is invoked (either by tap to play or autoplay), I still get crashes when letting the unminimized testcase run for a while, then pressing the Android back button. https://crash-stats.mozilla.com/report/index/bp-62e75bc0-0fee-49d2-8dbb-c17772120127 0 libdvm.so dvmAbort 1 libdvm.so JNI_CreateJavaVM 2 libdvm.so JNI_CreateJavaVM 3 libflashplayer.so libflashplayer.so@0x556089 4 libflashplayer.so libflashplayer.so@0x6f9af2 5 libflashplayer.so libflashplayer.so@0x75a606 6 libflashplayer.so libflashplayer.so@0x555ff3 7 libflashplayer.so libflashplayer.so@0x6ea97a 8 libflashplayer.so libflashplayer.so@0x5561ad 9 libflashplayer.so libflashplayer.so@0x75a606 10 libflashplayer.so libflashplayer.so@0x530029 etc.. https://crash-stats.mozilla.com/report/index/bp-b42d3857-258d-4d21-ba33-980492120127 0 libflashplayer.so libflashplayer.so@0x5439fc 1 libflashplayer.so libflashplayer.so@0x75a606 2 libxul.so PluginEventRunnable::Run dom/plugins/base/android/ANPEvent.cpp:56 3 libxul.so mozilla::AndroidBridge::ExecuteNextRunnable widget/android/AndroidBridge.cpp:1055 4 libxul.so Java_org_mozilla_gecko_GeckoAppShell_executeNextRunnable widget/android/AndroidJNI.cpp:228 5 libmozglue.so __res_nsend other-licenses/android/res_send.c:939 6 @0xf 7 app_process app_process@0x32 8 app_process app_process@0xaee This is on the LG Optimus Black, Android2.2.2. I guess this is a Flash crash?
Ya, both of them are flash crashes. I ran the script without ever invoking the flash on the Galaxy S II so I haven't crashed yet. Your test did make my mobile device nice and toasty warm. :)
Keywords: testcase
Summary: Crash [@ dvmStringLen | JNI_CreateJavaVM | mozilla::nsJNIString::nsJNIString] → Crash in mozilla::AndroidBridge::GetMimeTypeFromExtensions @ dvmStringLen | JNI_CreateJavaVM | mozilla::nsJNIString::nsJNIString
Component: General → Widget: Android
Product: Fennec → Core
QA Contact: general → android
Keywords: testcase
Assigning to blassey because he recently fixed some JNIString bugs in AndroidBridge.cpp.
Assignee: nobody → blassey.bugs
Crash Signature: [@ dvmStringLen] [@ dvmStringLen | JNI_CreateJavaVM | mozilla::nsJNIString::nsJNIString] → [@ dvmStringLen] [@ dvmStringLen | JNI_CreateJavaVM | mozilla::nsJNIString::nsJNIString] [@ mozilla::nsJNIString::nsJNIString]
Summary: Crash in mozilla::AndroidBridge::GetMimeTypeFromExtensions @ dvmStringLen | JNI_CreateJavaVM | mozilla::nsJNIString::nsJNIString → Crash in mozilla::AndroidBridge::GetMimeTypeFromExtensions
last crash with this signature was with buildid 20120503030512 so fix range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cc5254f9825f&tochange=807403a04a6a which is unfortunately huge, but I suspect http://hg.mozilla.org/mozilla-central/rev/2d619155c69b is the most likely fix so resolving as a dupe of that
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.