Closed
Bug 959391
Opened 10 years ago
Closed 10 years ago
B2G Assertion: MOZ_ASSERT(tabChild) in MissingRequiredTabChild during FTU
Categories
(Core :: Networking, defect)
Tracking
()
RESOLVED
FIXED
mozilla29
People
(Reporter: gwagner, Assigned: gwagner)
References
Details
(Whiteboard: [systemsfe])
Attachments
(1 file)
876 bytes,
patch
|
jdm
:
review+
|
Details | Diff | Splinter Review |
STR: Reproduces sometimes when going through privacy pages during FTU. Program received signal SIGSEGV, Segmentation fault. 0xb4dab954 in MissingRequiredTabChild (tabChild=<optimized out>, context=<optimized out>) at ../../../dist/include/mozilla/net/NeckoCommon.h:130 130 MOZ_ASSERT(tabChild); (gdb) bt #0 0xb4dab954 in MissingRequiredTabChild (tabChild=<optimized out>, context=<optimized out>) at ../../../dist/include/mozilla/net/NeckoCommon.h:130 #1 mozilla::net::MissingRequiredTabChild (tabChild=0x0, context=<optimized out>) at ../../../dist/include/mozilla/net/NeckoCommon.h:122 #2 0xb4dadf80 in mozilla::net::HttpChannelChild::AsyncOpen (this=0xb2417c00, listener=<optimized out>, aContext=0x0) at ../../../../netwerk/protocol/http/HttpChannelChild.cpp:1065 #3 0xb504d6aa in nsPrefetchNode::OpenChannel (this=0xb2691500) at ../../../uriloader/prefetch/nsPrefetchService.cpp:207 #4 0xb504d7d0 in nsPrefetchService::ProcessNextURI (this=0xb2691440) at ../../../uriloader/prefetch/nsPrefetchService.cpp:467 #5 0xb504da04 in nsPrefetchNode::OnStopRequest (this=0xb2691480, aRequest=<optimized out>, aContext=<optimized out>, aStatus=<optimized out>) at ../../../uriloader/prefetch/nsPrefetchService.cpp:310 #6 0xb4dac57a in mozilla::net::HttpChannelChild::OnStopRequest (this=0xb241ec00, statusCode=<optimized out>) at ../../../../netwerk/protocol/http/HttpChannelChild.cpp:458 #7 0xb4dacac6 in mozilla::net::HttpChannelChild::RecvOnStopRequest (this=0xb241ec00, statusCode=@0xbe88aa80) at ../../../../netwerk/protocol/http/HttpChannelChild.cpp:437 #8 0xb4ebd998 in mozilla::net::PHttpChannelChild::OnMessageReceived (this=0xb241ec00, __msg=...) at PHttpChannelChild.cpp:516 #9 0xb4eac5c6 in mozilla::dom::PContentChild::OnMessageReceived (this=0xb3e44c18, __msg=...) at PContentChild.cpp:3266 #10 0xb4e60dc4 in mozilla::ipc::MessageChannel::DispatchAsyncMessage (this=0xb3e44c48, aMsg=...) at ../../../ipc/glue/MessageChannel.cpp:1132 #11 0xb4e63cd0 in mozilla::ipc::MessageChannel::OnMaybeDequeueOne (this=0xb3e44c48) at ../../../ipc/glue/MessageChannel.cpp:1029 #12 0xb4e607d0 in DispatchToMethod<mozilla::ipc::MessageChannel, void (mozilla::ipc::MessageChannel::*)()> (method= (void (mozilla::ipc::MessageChannel::*)(mozilla::ipc::MessageChannel * const)) 0xb4e63c3d <mozilla::ipc::MessageChannel::OnMaybeDequeueOne()>, obj=<optimized out>, arg=<optimized out>) at ../../../ipc/chromium/src/base/tuple.h:383 #13 RunnableMethod<mozilla::ipc::MessageChannel, void (mozilla::ipc::MessageChannel::*)(), Tuple0>::Run (this=<optimized out>) at ../../../ipc/chromium/src/base/task.h:307 #14 0xb4e61238 in Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:376 #15 mozilla::ipc::MessageChannel::DequeueTask::Run (this=<optimized out>) at ../../dist/include/mozilla/ipc/MessageChannel.h:393 #16 0xb4e56cbc in MessageLoop::RunTask (this=0xbe88af00, task=0xb242e8e0) at ../../../ipc/chromium/src/base/message_loop.cc:344 #17 0xb4e575fa in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=<optimized out>) at ../../../ipc/chromium/src/base/message_loop.cc:352 #18 0xb4e586ee in DoWork (this=<optimized out>) at ../../../ipc/chromium/src/base/message_loop.cc:452 #19 MessageLoop::DoWork (this=0xbe88af00) at ../../../ipc/chromium/src/base/message_loop.cc:431 #20 0xb4e64d16 in mozilla::ipc::DoWorkRunnable::Run (this=<optimized out>) at ../../../ipc/glue/MessagePump.cpp:226 #21 0xb4cce712 in ProcessNextEvent (result=0xbe88ada7, mayWait=<optimized out>, this=0xb3e2f480) at ../../../xpcom/threads/nsThread.cpp:637 #22 nsThread::ProcessNextEvent (this=0xb3e2f480, mayWait=<optimized out>, result=0xbe88ada7) at ../../../xpcom/threads/nsThread.cpp:568 #23 0xb4c8a1f0 in NS_ProcessNextEvent (thread=0xb3e2f480, mayWait=<optimized out>) at ../../../xpcom/glue/nsThreadUtils.cpp:263 #24 0xb4e6518e in mozilla::ipc::MessagePump::Run (this=0xb3e01b80, aDelegate=0xbe88af00) at ../../../ipc/glue/MessagePump.cpp:134 #25 0xb4e56e02 in MessageLoop::RunInternal (this=0xbe88af00) at ../../../ipc/chromium/src/base/message_loop.cc:226 #26 0xb4e56e1a in RunHandler (this=0xbe88af00) at ../../../ipc/chromium/src/base/message_loop.cc:219 #27 MessageLoop::Run (this=0xbe88af00) at ../../../ipc/chromium/src/base/message_loop.cc:193 #28 0xb53b68a6 in nsBaseAppShell::Run (this=0xb3142a00) at ../../../widget/xpwidgets/nsBaseAppShell.cpp:161 #29 0xb5c25cfe in XRE_RunAppShell () at ../../../toolkit/xre/nsEmbedFunctions.cpp:679 #30 0xb4e65246 in mozilla::ipc::MessagePumpForChildProcess::Run (this=0xb3e01b80, aDelegate=0xbe88af00) at ../../../ipc/glue/MessagePump.cpp:251 #31 0xb4e56e02 in MessageLoop::RunInternal (this=0xbe88af00) at ../../../ipc/chromium/src/base/message_loop.cc:226 #32 0xb4e56e1a in RunHandler (this=0xbe88af00) at ../../../ipc/chromium/src/base/message_loop.cc:219 #33 MessageLoop::Run (this=0xbe88af00) at ../../../ipc/chromium/src/base/message_loop.cc:193 ---Type <return> to continue, or q <return> to quit---q 125 if (UsingNeckoIPCSecurity()) { 126 // Bug 833935: during navigation away from page some loads may lack 127 // TabParent: we don't want to kill browser for that. Doesn't happen in 128 // test harness, so fail in debug mode so we can catch new code that fails 129 // to pass security info. 130 MOZ_ASSERT(tabChild);
Assignee | ||
Comment 1•10 years ago
|
||
Assignee: nobody → anygregor
Assignee | ||
Updated•10 years ago
|
Attachment #8360114 -
Flags: review?(josh)
Comment 2•10 years ago
|
||
jdm isn't a necko peer, but I'm fine with granting him permission to review this. Looking over bug 833935, it was never clear why these errors happen, and it sounded like bz/jdm thought it would be hard to figure it out, too. So that's an argument for removing the ASSERT. OTOH it's a little sad to lose it, since ultimately this is a programming error on the part of the upper layer. But overall it sounds like the ASSERT needs to go, unless jdm or someone else has an idea on how to track down these weird docshells w/o tabinfo. (If jdm doesn't get to this soon, reassign to me and I'll r+)
Comment 3•10 years ago
|
||
Comment on attachment 8360114 [details] [diff] [review] 959391.diff Review of attachment 8360114 [details] [diff] [review]: ----------------------------------------------------------------- Ah well. I don't have any better ideas at this point.
Attachment #8360114 -
Flags: review?(josh) → review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Whiteboard: [systemsfe]
Comment 4•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/7454b84dea9e
Keywords: checkin-needed
Comment 5•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/7454b84dea9e
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla29
You need to log in
before you can comment on or make changes to this bug.
Description
•