Closed Bug 4747 Opened 26 years ago Closed 26 years ago

NECKO: [PP][CRASH-Linux] trying to load /~webteam/calendar/

Categories

(Core :: Networking, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: nisheeth_mozilla, Assigned: gagan)

References

()

Details

Try going to the above url with a Linux build. You'll crash with the following call stack: #0 0x40176376 in net_finish_setup_http_stream (ce=0x84847c8) at mkhttp.c:2963 #1 0x40175ac9 in net_setup_http_stream (ce=0x84847c8) at mkhttp.c:2645 #2 0x40177249 in net_ProcessHTTP (ce=0x84847c8) at mkhttp.c:3551 #3 0x40243003 in NET_ProcessNet (ready_fd=0x8417250, fd_type=2) at mkgeturl.c:3359 #4 0x4024aee1 in NET_PollSockets () at mkselect.c:298 #5 0x4026c342 in nsNetlibService::NetPollSocketsCallback (aTimer=0x8485ae8, aClosure=0x807d8f8) at nsNetService.cpp:1277 #6 0x40155de9 in TimerImpl::FireTimeout (this=0x8485ae8) at nsTimer.cpp:73 #7 0x401562d2 in nsTimerExpired (aCallData=0x8485ae8) at nsTimer.cpp:189 #8 0x40a59990 in g_timeout_dispatch (source_data=0x8377a38, current_time=0xbffffab0, user_data=0x8485ae8) at gmain.c:1147 #9 0x40a58c83 in g_main_dispatch (current_time=0xbffffab0) at gmain.c:647 #10 0x40a5920f in g_main_iterate (block=1, dispatch=1) at gmain.c:854 #11 0x40a59391 in g_main_run (loop=0x8200b08) at gmain.c:912 #12 0x4098644b in gtk_main () at gtkmain.c:475 #13 0x400921d8 in nsAppShell::Run (this=0x80744b0) at nsAppShell.cpp:208 #14 0x40017d55 in nsAppShellService::Run (this=0x8125718) at nsAppShellService.cpp:186 #15 0x804a8cc in main (argc=1, argv=0xbffffbd4) at nsAppRunner.cpp:337
QA Contact: 3819 → 4616
Moving over qa contacts and cc list from bug 3413...
Assignee: gagan → rickg
Target Milestone: M4
Another one of these timers. With win 4/5 build, I get parser core dump. nsCParserNode::GetKeyAt(unsigned int 2) line 250 + 3 bytes CreateContentObject(const nsIParserNode & {...}, nsHTMLTag eHTMLTag_img, nsIDOMHTMLFormElement * 0x00000000, nsIWebShell * 0x01100ce0, nsIHTMLContent * * 0x0012fbd0) line 800 + 18 bytes SinkContext::AddLeaf(const nsIParserNode & {...}) line 1079 + 35 bytes HTMLContentSink::AddLeaf(HTMLContentSink * const 0x03803960, const nsIParserNode & {...}) line 1979 + 15 bytes CNavDTD::AddLeaf(const nsIParserNode & {...}) line 2465 + 31 bytes CNavDTD::HandleDefaultStartToken(CToken * 0x01032bc0, nsHTMLTag eHTMLTag_img, nsIParserNode & {...}) line 985 + 12 bytes CNavDTD::HandleStartToken(CToken * 0x01032bc0) line 1181 + 25 bytes NavDispatchTokenHandler(CToken * 0x01032bc0, nsIDTD * 0x03746df0) line 243 + 12 bytes CTokenHandler::operator()(CToken * 0x01032bc0, nsIDTD * 0x03746df0) line 80 + 14 bytes CNavDTD::HandleToken(CNavDTD * const 0x03746df0, CToken * 0x01032bc0, nsIParser * 0x03803860) line 633 + 18 bytes CNavDTD::BuildModel(CNavDTD * const 0x03746df0, nsIParser * 0x03803860, nsITokenizer * 0x03746490, nsITokenObserver * 0x00000000, nsIContentSink * 0x03803960) line 501 + 20 bytes nsParser::BuildModel() line 847 + 34 bytes nsParser::ResumeParse(nsIDTD * 0x00000000) line 799 + 11 bytes nsParser::OnStopBinding(nsParser * const 0x03803864, nsIURL * 0x037f17e0, unsigned int 0, unsigned short * 0x037479e0) line 1026 + 17 bytes nsDocumentBindInfo::OnStopBinding(nsDocumentBindInfo * const 0x037f1760, nsIURL * 0x037f17e0, unsigned int 0, unsigned short * 0x037479e0) line 1986 + 30 bytes OnStopBindingProxyEvent::HandleEvent(OnStopBindingProxyEvent * const 0x03747990) line 591 + 45 bytes StreamListenerProxyEvent::HandlePLEvent(PLEvent * 0x03747994) line 471 + 12 bytes PL_HandleEvent(PLEvent * 0x03747994) line 476 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x00eceaa0) line 437 + 9 bytes _md_EventReceiverProc(void * 0x00020758, unsigned int 49323, unsigned int 0, long 15526560) line 799 + 9 bytes USER32!
Assignee: rickg → nisheeth
Nisheeth -- I think this is fixed now, but I don't have a linux box to test it. Can you please retry it? If it's still a problem-- send it back to me. Thanks.
Assignee: nisheeth → rickg
No, I still see this crash. But, I see the stack that I posted, not the one dp posted. Going by that stack it seems like this should be assigned to gagan. I'm ccing him and assigning this back to you, Rick.
Assignee: rickg → gagan
Gagan -- this no longer appears to crash in the parser (another fix corrected that I believe). However, there is a netlib problem which results in a lockup.
Summary: [CRASH-Linux] trying to load this url... → [CRASH-Linux] trying to load /~webteam/calendar/
Target Milestone: M4 → M6
Marking this till Necko lands...
Summary: [CRASH-Linux] trying to load /~webteam/calendar/ → [PP][CRASH-Linux] trying to load /~webteam/calendar/
Deffered till Necko lands...
Deferring till Necko lands...
Per DP's suggestion marking these till M8. Though Necko lands with M7, we will be able to verify it for M8.
I'm moving this to target M9, Necko will be enabled somewhere during late M8 or early M9. We will need to get on this and it cannot be postponed past the M9 milestone.
Changing all Networking Library/Browser bugs to Networking-Core component for Browser. Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do this in a bulk change. If this happens, I will fix. ;-)
Summary: [PP][CRASH-Linux] trying to load /~webteam/calendar/ → NECKO: [PP][CRASH-Linux] trying to load /~webteam/calendar/
Pl. verify with Necko.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Not seeing this anymore. Marking as fixed. Nisheeth verify.
my linux just keeps on trying to load this page forever with the 1999081308 build........
Status: RESOLVED → VERIFIED
I don't see this one now.
Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.
You need to log in before you can comment on or make changes to this bug.