If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

[@ RPCListener::OnExitedCall]

RESOLVED WORKSFORME

Status

()

Core
IPC
--
critical
RESOLVED WORKSFORME
7 years ago
6 years ago

People

(Reporter: timeless, Unassigned)

Tracking

({assertion, crash})

Trunk
ARM
Maemo
assertion, crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature, URL)

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
A tester triggered this by taking fennec e10s to nytimes.com. 5 subsequent tests by a QA person didn't reproduce it, but I'm filing so that I can have a public record of it.

0      0x42cf26f8       *__GI_raise  (sig=6)  at
1     0x42cf6df8     *__GI_abort () at abort.c:88
2     0x40060e7c     mozalloc_abort () at
3     0x413d2540     NS_DebugBreak_P (aSeverity=1121938428, aStr=0x4159fba8
4     0x407dcf10     mozilla::ipc::RPCChannel::RPCListener::OnExitedCall () at
5     0x407dd7b0     mozilla::net::HttpChannelChild::AsyncOpen
6     0x40870678     imgLoader::ValidateRequestWithNewChannel (this=0x4581e700,
7     0x40870a28     imgLoader::ValidateEntry (this=0x4581e700,
8     0x408722b4     imgLoader::LoadImage (this=0x4581e700, aURI=0x47bd1690,
9     0x40a60694     nsContentUtils::LoadImage (aURI=0x47bd1690,
10     0x40ab37ac     nsImageLoadingContent::LoadImage (this=0x47bd078c,
11     0x40ab3a5c     nsImageLoadingContent::LoadImage (this=0x47bd078c,
12     0x40b6cff0     nsHTMLImageElement::MaybeLoadImage (this=0x47bd0760) at
13     0x40b6e7c4     nsRunnableMethodImpl<void (this=0x4510bfa0) at
14     0x40a5fc58     nsContentUtils::RemoveScriptBlocker () at
15     0x40a8f318     nsDocument::EndUpdate (this=0x46e38800, aUpdateType=1) at
16     0x40bbd1c4     nsHTMLDocument::EndUpdate (this=0x0, aUpdateType=6203) at
17     0x40d65180     nsHtml5TreeOpExecutor::UpdateStyleSheet (this=0x47877c20,
18     0x40d6193c     nsHtml5TreeOperation::Perform (this=0x47ca8f88,
19     0x40d65a18     nsHtml5TreeOpExecutor::RunFlushLoop (this=0x47877c20) at
20     0x40d66044     nsHtml5ExecutorReflusher::Run () at
21     0x413c9564     nsThread::ProcessNextEvent (this=0x45328dd0, mayWait=0,
22     0x413878e0     NS_ProcessNextEvent_P (mayWait=0) at
23     0x41296c34     mozilla::ipc::MessagePump::Run (this=0x45326fd0,
24     0x414136d8     MessageLoop::RunInternal (this=0xbed68938) at
25     0x4141375c     MessageLoop::Run (this=0xbed68938) at
26     0x412285ec     nsBaseAppShell::Run (this=0x460792e8) at
27     0x40744ce4     XRE_RunAppShell () at
28     0x414136d8     MessageLoop::RunInternal (this=0xbed68938) at
29     0x4141375c     MessageLoop::Run (this=0xbed68938) at
30     0x40745128     XRE_InitChildProcess (aArgc=2, aArgv=0x45338180,
31     0x00009254     main (argc=3, argv=0xbed68bd4) at

Comment 1

7 years ago
I have a suspicion that this is a use-after-free error, and the HttpChannelChild is actually invalid here.

Comment 2

7 years ago
mikek can you run valgrind over this?
Created attachment 486320 [details]
Valgrind run 1
Created attachment 486321 [details]
Valgrind run 2
Created attachment 486322 [details]
Valgrind run 3
Except for some memory leaking and the errors caused by JS, this is the only thing that I found as sticking out (from the first trace) (I don't know yet if this could be the cause of any malfunctioning):

==542== Thread 2:
==542== Syscall param socketcall.sendmsg(msg.msg_iov[i]) points to uninitialised byte(s)
==542==    at 0x4E3BF2D: ??? (syscall-template.S:82)
==542==    by 0x7C56EE6: IPC::Channel::ChannelImpl::ProcessOutgoingMessages() (ipc_channel_posix.cc:623)
==542==    by 0x7C57167: IPC::Channel::ChannelImpl::Send(IPC::Message*) (ipc_channel_posix.cc:679)
==542==    by 0x7C57910: IPC::Channel::Send(IPC::Message*) (ipc_channel_posix.cc:822)
==542==    by 0x795312B: void DispatchToMethod<IPC::Channel, bool (IPC::Channel::*)(IPC::Message*), IPC::Message*>(IPC::Channel*, bool (IPC::Channel::*)(IPC::Message*), Tuple1<IPC::Message*> const&) (tuple.h:393)
==542==    by 0x7952ECB: RunnableMethod<IPC::Channel, bool (IPC::Channel::*)(IPC::Message*), Tuple1<IPC::Message*> >::Run() (task.h:307)
==542==    by 0x7BEA2F5: MessageLoop::RunTask(Task*) (message_loop.cc:343)
==542==    by 0x7BEA365: MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) (message_loop.cc:351)
==542==    by 0x7BEA763: MessageLoop::DoWork() (message_loop.cc:451)
==542==    by 0x7C44785: base::MessagePumpLibevent::Run(base::MessagePump::Delegate*) (message_pump_libevent.cc:309)
==542==    by 0x7BE9E00: MessageLoop::RunInternal() (message_loop.cc:219)
==542==    by 0x7BE9D85: MessageLoop::RunHandler() (message_loop.cc:202)
==542==  Address 0x1c3f83a0 is not stack'd, malloc'd or (recently) free'd
==542==  Uninitialised value was created by a stack allocation
==542==    at 0x7996926: mozilla::dom::PBrowserParent::OnMessageReceived(IPC::Message const&, IPC::Message*&) (PBrowserParent.cpp:1183)
==542==

Comment 7

7 years ago
that is unrelated (i filed a bug about it).

sounds like we can't reproduce it any longer.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
(Assignee)

Updated

6 years ago
Crash Signature: [@ RPCListener::OnExitedCall]
You need to log in before you can comment on or make changes to this bug.