Closed Bug 774599 Opened 12 years ago Closed 12 years ago

Crash when content of unknown MIME type is encountered

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

(blocking-basecamp:+)

VERIFIED FIXED
blocking-basecamp +

People

(Reporter: romaxa, Assigned: fabrice)

References

Details

(Keywords: crash, reproducible, Whiteboard: [LOE:M] [WebAPI:P0])

Crash Data

Attachments

(1 file)

Program received signal SIGSEGV, Segmentation fault.
0x3b4918f6 in mozilla::dom::ExternalHelperAppParent::RecvOnStartRequest (this=0x616630, entityID=<value optimized out>)
    at B2G/gecko/uriloader/exthandler/ExternalHelperAppParent.cpp:67
67	  mStatus = mListener->OnStartRequest(this, nsnull);
(gdb) bt 
#0  0x3b4918f6 in mozilla::dom::ExternalHelperAppParent::RecvOnStartRequest (this=0x616630, entityID=<value optimized out>)
    at B2G/gecko/uriloader/exthandler/ExternalHelperAppParent.cpp:67
#1  0x3b5eb9a8 in mozilla::dom::PExternalHelperAppParent::OnMessageReceived (this=0x616630, __msg=...)
    at B2G/objdir-gecko/ipc/ipdl/PExternalHelperAppParent.cpp:215
#2  0x3b606a52 in mozilla::dom::PContentParent::OnMessageReceived (this=0x35c858, __msg=...)
    at B2G/objdir-gecko/ipc/ipdl/PContentParent.cpp:1143
#3  0x3b5e51b0 in mozilla::ipc::AsyncChannel::OnDispatchMessage (this=0x35c860, msg=...) at B2G/gecko/ipc/glue/AsyncChannel.cpp:473
#4  0x3b5e9b1a in mozilla::ipc::RPCChannel::OnMaybeDequeueOne (this=0x35c860) at B2G/gecko/ipc/glue/RPCChannel.cpp:402
#5  0x3b5d9e16 in DispatchToMethod<mozilla::plugins::PluginInstanceChild, void (mozilla::plugins::PluginInstanceChild::*)()> (this=<value optimized out>)
    at B2G/gecko/ipc/chromium/src/base/tuple.h:383
#6  RunnableMethod<mozilla::plugins::PluginInstanceChild, void (mozilla::plugins::PluginInstanceChild::*)(), Tuple0>::Run (this=<value optimized out>)
    at B2G/gecko/ipc/chromium/src/base/task.h:307
#7  0x3b5e84d0 in mozilla::ipc::RPCChannel::RefCountedTask::Run (this=<value optimized out>) at ../../dist/include/mozilla/ipc/RPCChannel.h:430
#8  mozilla::ipc::RPCChannel::DequeueTask::Run (this=<value optimized out>) at ../../dist/include/mozilla/ipc/RPCChannel.h:453
#9  0x3b6ac704 in MessageLoop::RunTask (this=0x1a0d8, task=0xaed9181c) at B2G/gecko/ipc/chromium/src/base/message_loop.cc:326
#10 0x3b6ad552 in MessageLoop::DeferOrRunPendingTask (this=0x35c860, pending_task=<value optimized out>)
    at B2G/gecko/ipc/chromium/src/base/message_loop.cc:334
#11 0x3b6ae130 in MessageLoop::DoWork (this=0x1a0d8) at B2G/gecko/ipc/chromium/src/base/message_loop.cc:434
#12 0x3b5e7f84 in mozilla::ipc::MessagePump::Run (this=0xf598, aDelegate=0x1a0d8) at B2G/gecko/ipc/glue/MessagePump.cpp:86
#13 0x3b6ac6b4 in MessageLoop::RunInternal (this=0x3bad24b1) at B2G/gecko/ipc/chromium/src/base/message_loop.cc:208
#14 0x3b6ac76a in MessageLoop::RunHandler (this=0x1a0d8) at B2G/gecko/ipc/chromium/src/base/message_loop.cc:201
#15 MessageLoop::Run (this=0x1a0d8) at B2G/gecko/ipc/chromium/src/base/message_loop.cc:175
#16 0x3b57addc in nsBaseAppShell::Run (this=0x1e2560) at B2G/gecko/widget/xpwidgets/nsBaseAppShell.cpp:163
#17 0x3b4bad74 in nsAppStartup::Run (this=0x1e2508) at B2G/gecko/toolkit/components/startup/nsAppStartup.cpp:257
#18 0x3af43d32 in XREMain::XRE_mainRun (this=0xaed91a5c) at B2G/gecko/toolkit/xre/nsAppRunner.cpp:3787
#19 0x3af464b8 in XREMain::XRE_main (this=0xaed91a5c, argc=<value optimized out>, argv=0xaed93c44, aAppData=<value optimized out>)
    at B2G/gecko/toolkit/xre/nsAppRunner.cpp:3864
#20 0x3af46604 in XRE_main (argc=1, argv=0xaed93c44, aAppData=0xa980, aFlags=<value optimized out>)
    at B2G/gecko/toolkit/xre/nsAppRunner.cpp:3940
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) frame 0
#0  0x3b4918f6 in mozilla::dom::ExternalHelperAppParent::RecvOnStartRequest (this=0x616630, entityID=<value optimized out>)
    at B2G/gecko/uriloader/exthandler/ExternalHelperAppParent.cpp:67
67	  mStatus = mListener->OnStartRequest(this, nsnull);
(gdb) p mListener
$1 = {<nsCOMPtr_base> = {mRawPtr = 0x0}, <No data fields>}
(gdb)
Severity: normal → critical
Crash Signature: [@ mozilla::dom::ExternalHelperAppParent::RecvOnStartRequest]
Keywords: crash
From michelleluna:

Steps to reproduce:

    go to PianoTeaching.com
    tap the Half-Time show play button
    phone reboots [ed: b2g process crashes and restarts]

This is 100% reproducible for me.

(gdb) f 4
#4  0x415bdc52 in mozilla::dom::ExternalHelperAppParent::RecvOnStartRequest (this=0x221ddb0, entityID=...) at /home/cjones/mozilla/inbound/uriloader/exthandler/ExternalHelperAppParent.cpp:67
(gdb) p entityID
$1 = (const nsCString &) @0xbee5de54: {
  <nsACString_internal> = {
    mData = 0x330ce90 "%222040fc1-ef72e-4bf7d7cea07b1%22/980782/Tue, 08 May 2012 02:53:14 GMT", 
    mLength = 70, 
    mFlags = 5
  }, <No data fields>}

Whatever the entity ID is ...

I don't know what kind of media file we're trying to play here, will check on desktop.
blocking-basecamp: --- → +
The response from the server here is

HTTP/1.1 200 OK
Date: Sat, 18 Aug 2012 01:56:52 GMT
Server: Apache/2.2.22
Last-Modified: Tue, 08 May 2012 02:53:14 GMT
ETag: "2040fc1-ef72e-4bf7d7cea07b1"
Accept-Ranges: bytes
Content-Length: 980782
Vary: User-Agent
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: audio/mpeg

so nothing silly like serving octet-stream.

Guys, any ideas why we don't recognize this as playable content and just navigate to it?
Keywords: reproducible
There are really two separate bugs here
 - unknown content causes the b2g process to crash, bad.  Looks like we expect to have some sort of platform/frontend-specific fallback content sink but there isn't one for b2g.  We need to implement this as a safeguard against unknown MIME types.

 - mp3/mp4 behave like unknown content types, even though (on gonk) we can play them with native controls
Component: File Handling → General
Product: Core → Boot2Gecko
Summary: [B2G] gecko crashes on attempt to open mp3 or mp4 files → Crash when content of unknown MIME type is encountered
Gaia issue that's tracking this btw - https://github.com/mozilla-b2g/gaia/issues/2929
I think what we want to do here is add a "real" implementation of uriloader/exthandler/gonk that converts unhandled content into web activities.  Cargo-culting the C++ side of this looks pretty easy, but I'm not sure
 - how to initiate a new activity from C++
 - what to do if there's no handler for the activity
 - if there is a handler, how to transfer the content bytes (in-memory Blob I guess?)

Using this implementation to hook the pdf.js app into b2g, generically, would be a nice target.
Looks like it's trying to load a plugin and doesn't even touch our media code.
I tried to reproduce. I got to "pianoteaching.com" and it redirects to "pianoadventures.com" and I see no sign of a "half time play button".
Oh, sorry: patch in bug 783736.  You're right! :)  (s/plugin/external application/)
(In reply to Chris Double (:doublec) from comment #9)
> I tried to reproduce. I got to "pianoteaching.com" and it redirects to
> "pianoadventures.com" and I see no sign of a "half time play button".

The link is in an "ad" embedded on the page.  Would recommend using http://people.mozilla.com/~cjones/media.html --- the MP3 link goes to the same content.
(In reply to Chris Jones [:cjones] [:warhammer] from comment #7)
> I think what we want to do here is add a "real" implementation of
> uriloader/exthandler/gonk that converts unhandled content into web
> activities.  Cargo-culting the C++ side of this looks pretty easy, but I'm
> not sure
>  - how to initiate a new activity from C++
>  - what to do if there's no handler for the activity
>  - if there is a handler, how to transfer the content bytes (in-memory Blob
> I guess?)
> 
> Using this implementation to hook the pdf.js app into b2g, generically,
> would be a nice target.

We already hooked up pdf.js with b2g/components/ContentHandler.js that leads to firing a "view" activity here: https://mxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.js#326

A nice followup would be to register components for all the "view" activities that are registered. But this is what navigator.registerContentHandler() should do also...

For unknown types, nsIExternalURLHandlerService is probably what we want.
Justin, can you take this?
Assignee: nobody → justin.lebar+bug
(In reply to Andrew Overholt [:overholt] from comment #13)
> Justin, can you take this?

I can, although it's somewhat out of my depth and I have plenty of bugs in my depth, so if someone else has time, they should grab this...
(In reply to Justin Lebar [:jlebar] from comment #14)
> (In reply to Andrew Overholt [:overholt] from comment #13)
> > Justin, can you take this?
> 
> I can, although it's somewhat out of my depth and I have plenty of bugs in
> my depth, so if someone else has time, they should grab this...

Stealing.
Assignee: justin.lebar+bug → 21
Whiteboard: [LOE:M] → [LOE:M] [WebAPI:P0]
Vivien, are you actually going to work on this?  If not, we should unassign you from the bug so the PMs can find a new owner.
(In reply to Justin Lebar [:jlebar] from comment #16)
> Vivien, are you actually going to work on this?  If not, we should unassign
> you from the bug so the PMs can find a new owner.

I will but I'm a bit under water for now so I can't tell when I will start :/
Attached patch patchSplinter Review
I found why we crashed by reading a comment in the android code (https://mxr.mozilla.org/mozilla-central/source/uriloader/exthandler/android/nsOSHelperAppService.cpp#34).

Since we don't have any external application fallback, the fix just makes sure that we don't return a null pointer for the nsIMIMEInfo object.
Assignee: 21 → fabrice
Attachment #661560 - Flags: review?(justin.lebar+bug)
Attachment #661560 - Flags: review?(jones.chris.g)
Also, I have a test page at https://people.mozilla.com/~fdesre/handler/
The ".rar file" link crashes without the patch, but not with the patch.
Attachment #661560 - Flags: review?(justin.lebar+bug) → review+
Attachment #661560 - Flags: review?(jones.chris.g)
https://hg.mozilla.org/mozilla-central/rev/92871b1b9608
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Keywords: verifyme
QA Contact: jsmith
Verified on 9/19 build.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.