Closed Bug 959391 Opened 10 years ago Closed 10 years ago

B2G Assertion: MOZ_ASSERT(tabChild) in MissingRequiredTabChild during FTU

Categories

(Core :: Networking, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla29

People

(Reporter: gwagner, Assigned: gwagner)

References

Details

(Whiteboard: [systemsfe])

Attachments

(1 file)

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);
Attached patch 959391.diffSplinter Review
Assignee: nobody → anygregor
Attachment #8360114 - Flags: review?(josh)
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 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+
Keywords: checkin-needed
Whiteboard: [systemsfe]
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.

Attachment

General

Created:
Updated:
Size: