Linux is crashing on 5/3 builds in both viewer and apprunner at http://www.disney.go.com - Mac and Windows do not crash. I will attempt to create a minimized test case but no promises, it is an ugly page.

Ramiro -- please check into this, at least to provide a stack trace. Then reassign it as needed, or give it back to me to do so. Thanks for your help.

Marking M5 since this is one of the smoketests. I was unable to narrow this bug down, sans debugger.

don also sees some instability with the latest on golfweb and zdnet.... are the latest m5 build in bad shape on linux?

I'm crashing at zdnet.com on all three platforms. Golfweb hangs the mac, and crashes on linux/win95 after a bit.

made a new bug, 5889, for zdnet crash, complete with windows talkback trace :-)

Adding comments from kipp: 5879 (www.disney.go.com) dies in the bowels of netlib. I wouldn't hold up M5 for it. Here is the stack crawl in case somebody can pop up a miracle: #0 0x40673d42 in net_ProcessHTTP (ce=0x81deaf0) at mkhttp.c:3577 #1 0x406e1f17 in NET_ProcessNet (ready_fd=0x811eab8, fd_type=2) at mkgeturl.c:3355 #2 0x406e9ea5 in NET_PollSockets () at mkselect.c:320 #3 0x406bdb02 in nsNetlibService::NetPollSocketsCallback (aTimer=0x81a8068, aClosure=0x81412d8) at nsNetService.cpp:1263 #4 0x40524de9 in TimerImpl::FireTimeout (this=0x81a8068) at nsTimer.cpp:73 #5 0x405252d2 in nsTimerExpired (aCallData=0x81a8068) at nsTimer.cpp:189 #6 0x40a0eb10 in g_timeout_dispatch (source_data=0x816a878, current_time=0xbffff690, user_data=0x81a8068) at gmain.c:1214 #7 0x40a0df2b in g_main_dispatch (current_time=0xbffff690) at gmain.c:656 #8 0x40a0e46f in g_main_iterate (block=1, dispatch=1) at gmain.c:865 #9 0x40a0e5b9 in g_main_run (loop=0x81607b8) at gmain.c:923 #10 0x4097950b in gtk_main () at gtkmain.c:475 #11 0x40054160 in nsAppShell::Run (this=0x807aa70) at nsAppShell.cpp:203 #12 0x8054bd2 in nsNativeViewerApp::Run (this=0x80727c0) at nsGTKMain.cpp:42 #13 0x8054d9e in main (argc=2, argv=0xbffff770) at nsGTKMain.cpp:89 Here is the source at the crash site: 3573 case HTTP_DONE: 3574 TIMING_STOPCLOCK_NAME("http:xfer", ce->URL_s->address, 3575 ce->window_id, "ok"); 3576 3577 NET_ClearReadSelect(ce->window_id, cd->connection->sock); 3578 NET_TotalNumberOfOpenConnections--; cd.connection points to free memory. Purify on solaris might help debug this...

Adding comments from akkana: I saw a crash today on a netcenter page with basically the same stack trace; filed http://bugzilla.mozilla.org/show_bug.cgi?id=5884 which was latered to M6 because the Necko landing may fix it.

Adding comments from dp: This is a stack I see often. Esp. with My Netscape but not consistently. Of course, there is Timer stuff on the stack. I would love to fix this but the current netlib is unweildy. Necko will certainly have different bugs :-) I will see what I can do about this for M6.

Marking M6, assigned to dp.

Here's the call stack from talkback: Call Stack: (Signature = 0x089bc561 82083039) 0x089bc561 nsFrameList::DeleteFrames [d:\builds\seamonkey\mozilla\ layout\base\src\nsFrameList.cpp, line 29] nsContainerFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsContainerFrame.cpp, line 82] nsTableFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\table\src\nsTableFrame.cpp, line 350] nsFrameList::DeleteFrames [d:\builds\seamonkey\mozilla\ layout\base\src\nsFrameList.cpp, line 29] nsContainerFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsContainerFrame.cpp, line 82] nsLineBox::DeleteLineList [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsLineBox.cpp, line 158] nsBlockFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsBlockFrame.cpp, line 804] nsAreaFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsAreaFrame.cpp, line 102] nsFrameList::DeleteFrames [d:\builds\seamonkey\mozilla\ layout\base\src\nsFrameList.cpp, line 29] nsContainerFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsContainerFrame.cpp, line 82] nsFrameList::DeleteFrames [d:\builds\seamonkey\mozilla\ layout\base\src\nsFrameList.cpp, line 29] nsContainerFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsContainerFrame.cpp, line 82] nsFrameList::DeleteFrames [d:\builds\seamonkey\mozilla\ layout\base\src\nsFrameList.cpp, line 29] nsContainerFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsContainerFrame.cpp, line 82] nsFrameList::DeleteFrames [d:\builds\seamonkey\mozilla\ layout\base\src\nsFrameList.cpp, line 29] nsContainerFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsContainerFrame.cpp, line 82] nsTableFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\table\src\nsTableFrame.cpp, line 350] nsFrameList::DeleteFrames [d:\builds\seamonkey\mozilla\ layout\base\src\nsFrameList.cpp, line 29] nsContainerFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsContainerFrame.cpp, line 82] nsFrameList::DeleteFrames [d:\builds\seamonkey\mozilla\ layout\base\src\nsFrameList.cpp, line 29] nsBlockFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsBlockFrame.cpp, line 808] nsLineBox::DeleteLineList [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsLineBox.cpp, line 158] nsBlockFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsBlockFrame.cpp, line 804] nsAreaFrame::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsAreaFrame.cpp, line 102] nsFrameList::DeleteFrame [d:\builds\seamonkey\mozilla\ layout\base\src\nsFrameList.cpp, line 115] RootFrame::Reflow [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsHTMLFrame.cpp, line 163] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsContainerFrame.cpp, line 405] nsScrollFrame::Reflow [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsScrollFrame.cpp, line 399] nsContainerFrame::ReflowChild [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsContainerFrame.cpp, line 405] ViewportFrame::Reflow [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsViewportFrame.cpp, line 434] nsHTMLReflowCommand::Dispatch [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsHTMLReflowCommand.cpp, line 170] PresShell::ProcessReflowCommands [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsPresShell.cpp, line 1225] PresShell::ExitReflowLock [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsPresShell.cpp, line 658] PresShell::ReconstructFrames [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsPresShell.cpp, line 1692] PresShell::StyleSheetAdded [d:\builds\seamonkey\mozilla\ layout\html\base\src\nsPresShell.cpp, line 1700] nsHTMLDocument::InsertStyleSheetAt [d:\builds\seamonkey\mozilla\ layout\html\document\src\nsHTMLDocument.cpp, line 526] HTMLContentSink::LoadStyleSheet [d:\builds\seamonkey\mozilla\ layout\html\document\src\nsHTMLContentSink.cpp, line 3138] nsDoneLoadingStyle [d:\builds\seamonkey\mozilla\ layout\html\document\src\nsHTMLContentSink.cpp, line 2189] nsUnicharStreamLoader::OnStopBinding [d:\builds\seamonkey\mozilla\ network\module\nsNetStreamLoader.cpp, line 158] nsDocumentBindInfo::OnStopBinding [d:\builds\seamonkey\mozilla\ webshell\src\nsDocLoader.cpp, line 2099] OnStopBindingProxyEvent::HandleEvent [d:\builds\seamonkey\mozilla\ network\module\nsNetThread.cpp, line 592] StreamListenerProxyEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\ network\module\nsNetThread.cpp, line 472] PL_HandleEvent [plevent.c, line 477] PL_ProcessPendingEvents [plevent.c, line 438] _md_EventReceiverProc [plevent.c, line 803] KERNEL32.DLL + 0x3663 (0xbff73663) KERNEL32.DLL + 0x22894 (0xbff92894) 0x00778c54

how random is this? breakdown by platform would be good..

working ok on win95 with 5/20 build. loaded the page many times.

comment from el don > > Linux: > > ftp://sweetlou/products/client/seamonkey/linux_glibc/2.0/x86/1999-05-21-08-M6 > > > > Passes all automated tests, except for the abcnews and disney.go redirect > > tests (i'm not sure if there is a bug assigned for this or not, as the urls > > load by hand just fine); > > disney.go on linux... (random crash? ) I could use some more data on this > to help plan M6 wrap up... > > http://bugzilla.mozilla.org/show_bug.cgi?id=5879 Actually this is now what I use to test talkback. It crashes by hand about half the time, loads incorrectly another half. Someone should sit and try several things with it to pin down what the problem is. -- -=-=-=-=-=-=- Don McCasland donm@netscape.com

Warren gets netlib bugs.

moving to m7. lets get the Delete Frames bug logged somewhere else..

The stack trace I did on 5/10 was with Windows 95.

I can only duplicate this on Linux, about 50% of the time. Petersen said he will file a new bug if he sees the frames crash again on win95. Setting self as QA contact.

I can't reproduce this crash at www.disney.go.com on Win32 or Mac builds (5/24/ 99). This is a problem still on Linux.

Reevaluate after necko landing.

*** Bug 9522 has been marked as a duplicate of this bug. ***

This crash is now happening on the Mac July 16th build (1999071608).

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. ;-)

www.disney.go.com isn't crashing now, but the page ends up blank. I suspect a redirect problem. Gagan, can you evaluate? Thanks,

*** Bug 6324 has been marked as a duplicate of this bug. ***

funny that www.espn.go.com is working. does it use the same redirection?

The data seems to be passing on fine thru Necko. I would appreciate if someone from the layout team verifies that the blank window is indeed a frames problem. From what I saw the page has 2 frames and absolutely no data for non-frames situation. Reassigning to ramiro (?) for comments.

I see the same thing on both windows and unix.

I resummarizing the summary. This doesnt crash for me either on Linux and NT. So im taking it off the m9 radar. Im reassigning it to Vidur to look at the JavaScript detection code.

I have a fix in my tree - waiting for the tree to open. Ramiro says that he'll try to get my fix into the M9 branch as well. document.cookies got broken when Necko first landed and was never fixed. As a result scripts accessing document.cookies failed silently.

Fixed the document.cookies problem in the M10/M11 tip. Reassigning to Ramiro so he check in the same fix for the M9 branch.

I checked in the fix to the m9 branch. Marking fixed.

With the Sept 2 build, this problem has been fixed.

Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.