Closed Bug 1140714 Opened 9 years ago Closed 9 years ago

(e10s) ContentParent::RecvOpenAnonymousTemporaryFile is failure prone

Categories

(Core :: DOM: Content Processes, defect)

x86_64
Windows 7
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla39
Tracking Status
e10s m6+ ---
firefox39 --- fixed

People

(Reporter: jimm, Assigned: jld)

References

Details

Attachments

(1 file)

http://www.mathies.com/mozilla/bug1116884.txt

KillHard child signature breakdown:
-----------------------------------
50	49.5%	mozilla::dom::PContentChild::SendOpenAnonymousTemporaryFile(mozilla::ipc::FileDescriptor *)
21	20.8%	mozilla::net::PCookieServiceChild::SendGetCookieString(mozilla::ipc::URIParams const &,bool const &,bool const &,IPC::SerializedLoadContext const &,nsCString *)
7	6.9%	mozilla::dom::PBrowserChild::SendGetInputContext(int *,int *,int *)
6	5.9%	mozilla::dom::PBrowserChild::SendGetRenderFrameInfo(mozilla::layout::PRenderFrameChild *,mozilla::layers::TextureFactoryIdentifier *,unsigned __int64 *)
6	5.9%	mozilla::dom::PScreenManagerChild::SendScreenForBrowser(mozilla::dom::IdType<mozilla::dom::TabParent> const &,mozilla::dom::ScreenDetails *,bool *)
5	5.0%	mozilla::dom::PContentChild::SendLoadPlugin(unsigned int const &,nsresult *)

Failure type:
'(msgtype=0x3600BA,name=PContent::Msg_OpenAnonymousTemporaryFile) Processing error: message was deserialized, but the handler returned false (indicating failure)'

http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.cpp#4458

This looks kind of serious. File descriptor related maybe?
Maybe PContent::OpenAnonymousTemporaryFile should pass the nsresult back to the child in case of failure, instead of causing a failure in the handler?  It'd be nice to know why it's failing, though.
(In reply to Jed Davis [:jld] from comment #1)
> Maybe PContent::OpenAnonymousTemporaryFile should pass the nsresult back to
> the child in case of failure, instead of causing a failure in the handler? 
> It'd be nice to know why it's failing, though.

You could annotate crash reports with your hresult if you know you're going to return false and crash the child. We have some apis for this in ContentParent.

http://mxr.mozilla.org/mozilla-central/source/dom/ipc/ContentParent.h#245

I would add though, fixing this so that we return the failure over ipc and not crash.. and maybe report the failure in some other way would be preferred.
Assignee: nobody → jld
This makes NS_OpenAnonymousTemporaryFile fail the same way whether or not it's in a content process, which seems reasonable.

It's not really expected to fail, and there's no good way to force it to fail (the failure modes I can think of are TmpD space exhaustion and racing with another process that deletes the file between the CreateUnique and the open), so there's no test coverage for this path; I don't know if it's worth trying to do something about that.
Attachment #8575405 - Flags: review?(wmccloskey)
tracking-e10s: --- → m6+
Attachment #8575405 - Flags: review?(wmccloskey) → review+
https://hg.mozilla.org/mozilla-central/rev/35e0cd86eb83
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
no longer showing up, thanks!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.