On Windows 98: -start browser -go to http://home.netscape.com/ja/index1.html -before it even loads it crashes -commercial build 2000-07-12-11-M17 Stack Trace: FrameManager::RestoreFrameStateFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1592] PresShell::EndLoad [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 2355] nsDocument::EndLoad [d:\builds\seamonkey\mozilla\layout\base\src\nsDocument.cpp, line 1747] nsHTMLDocument::EndLoad [d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLDocument.cpp, line 848] HTMLContentSink::DidBuildModel [d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp, line 2380] GKHTML.DLL + 0x13f95c (0x602df95c) nsXMLDocument::AddRef [d:\builds\seamonkey\mozilla\layout\xml\document\src\nsXMLDocument.cpp, line 232] 0x107d8b57

I'm using build 2000-07-12-08-M17 in win98 JA and can't reproduce the problem. There doesn't appear to be a 2000-07-12-11-M17 build in sweetlou. Gary Liu

I could not reproduce this, either. When Alek tried it again, it works fine. I think when he tried the first time, the server side was doing something the page. I mark this as worksforme.

I am seeing a crash with the current Netscape JA page 1 out 8-10 times when it is loaded. Try something like this a numberof times from the Command line: netscp6 -url http://home.netscape.com/ja So far I've crashed 3 times out of 20 or so times, with 7/12/2000 Win32 build.

reopening. For complete copy of StackTrace: http://babel/stacktrace/14046627.htm (Netscape internal)

The call stack info is almost empty. Has anybody seen a different call stack? Call Stack: (Signature = 0x0012fa92 d1108505) 0x0012fa92

OK. I can reproduce a crash with Netscape Japan Home Page consistently now. (Nearly100% if you follow the following steps -- at leats it is that ferquent on my WinNT4-J.) 1. Set the Pref: Navigator: Startup Page: to "blank". 2. If there is any URL in the Home Page Location field in the same window below, delete the URL and leave this field blank. (This does not seem to be essential but this will increase the chance of a crash greatly) 3. Make sure that in the Browser encoding menu, Japanese Auto-Detection is OFF, and Western (ISO-8859-1) is chosen as the default. 4. Now quit Mozilla and re-start. 5. You should see a blank Browser window with MySidebar open on the left. 6. In the Location field, type in the following URL and hit CR: http://home.netscape.com/ja 7. You should see a crash as the page loads. I can reproduce this problem nearly 100% now.

Here's the Talkback dump for the crashes caused by the above set of stpes: =------------------------------------- Trigger Type: Program Crash Trigger Reason: Access violation Thread ID: 40 Call Stack: (Signature = FrameManager::RestoreFrameStateFor be7a957a) FrameManager::RestoreFrameStateFor [d:\builds\seamonkey\mozilla\layout\html\base\src\nsFrameManager.cpp, line 1592] PresShell::EndLoad [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 2355] nsDocument::EndLoad [d:\builds\seamonkey\mozilla\layout\base\src\nsDocument.cpp, line 1747] nsHTMLDocument::EndLoad [d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLDocument.cpp, line 848] HTMLContentSink::DidBuildModel [d:\builds\seamonkey\mozilla\layout\html\document\src\nsHTMLContentSink.cpp, line 2380] gkhtml.dll + 0x13f95c (0x602df95c) nsXMLDocument::AddRef [d:\builds\seamonkey\mozilla\layout\xml\document\src\nsXMLDocument.cpp, line 232] =------------------------------------- They seem to be identical to the one the original reporter attached to the report. I raised the severity of this bug. We really shoud not be crashing on Netscape Japan Home Page. If someone else can also consistently reproduce this problem, then we should probably nominate this for nsbeta2.

Putting on [nsbeta2+] radar.

Reassign to pollmann since it's crashing at his code in nsFrameManager.cpp.

I reloaded the page about 25 times on JA Netscape Page with the lastest Win32 2000-07-13-08-M17 and it didn't crash once. Someone else want to try this out with todays build?

I tried today's build (7/13/2000 Win32) and I still crash consistently. You need to follow the steps I described above precisely. One additional factor I found, given the steps above and comparing the case when the Sidebar is open as oppposed to when it is closed: Above Coditions + Sidebar closed -- crashes about 40-50% of the time Above Conditions + Sidebar open -- crashes over 90% of the times I seem to get more reproducibility with the Sidebar open.

I used the steps to reproduce the crash and i reproduce it most of the time now using the newest commercial build as well.

This may be related to bug 45288. I have a fix for 45288 in my tree and I can not reproduce the crash. (The code I change gets hit when loading up the test page because it has a charset specified in a <meta> tag) I'll see if I can reproduce the crash if I remove the fix for 45288

I am able to reproduce the crash if I remove my fix for bug 45288. I am not able to reproduce the crash with my fix. Radha, can you review this fix please? (attached to the report for bug bug 45288) Thanks!

Giving this to you Radha, per our phonecall.

Uhhhh ... what was the phone call about? :-)

The crash is actually due to a change that went in for Session History in frames. I came up with a fix that is in this code. Since Radha is the expert in that code (she wrote it!), she requested to take ownership of this bug.

eric, can you try these patches for the crash. I couldn't reproduce the crash anyway. This s'd also fix the urls in 45288

Radha, I still crash with your patch, the stack is different though: ns_if_addref(nsILayoutHistoryState * 0x03546200) line 1090 + 15 bytes PresShell::CaptureHistoryState(PresShell * const 0x035eed80, nsILayoutHistoryState * * 0x0012f758, int 1) line 2933 + 21 bytes nsDocShell::PersistLayoutHistoryState(nsDocShell * const 0x035abab0) line 3451 + 52 bytes nsDocShell::Embed(nsDocShell * const 0x035abad0, nsIContentViewer * 0x035e1940, const char * 0x0036f334, nsISupports * 0x00000000) line 2203 nsWebShell::Embed(nsWebShell * const 0x035abad0, nsIContentViewer * 0x035e1940, const char * 0x0036f334, nsISupports * 0x00000000) line 588 nsDocShell::CreateContentViewer(nsDocShell * const 0x035abab0, const char * 0x0012f904, nsIChannel * 0x03533f20, nsIStreamListener * * 0x0012f958) line 2360 + 32 bytes nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x035ab790, const char * 0x0012f904, int 0, const char * 0x1009fbf0 gCommonEmptyBuffer, nsIChannel * 0x03533f20, nsIStreamListener * * 0x0012f958, int * 0x0012f8e8) line 100 + 33 bytes nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x03533f20, nsISupports * 0x00000000) line 359 + 109 bytes nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x035354a0, nsIChannel * 0x03533f20, nsISupports * 0x00000000) line 233 + 16 bytes nsHTTPFinalListener::OnStartRequest(nsHTTPFinalListener * const 0x03536fc0, nsIChannel * 0x03533f20, nsISupports * 0x00000000) line 1157 InterceptStreamListener::OnStartRequest(InterceptStreamListener * const 0x035f7c20, nsIChannel * 0x03533f20, nsISupports * 0x00000000) line 1140 nsHTTPServerListener::FinishedResponseHeaders() line 1082 + 48 bytes nsHTTPServerListener::OnDataAvailable(nsHTTPServerListener * const 0x035f7a90, nsIChannel * 0x03535754, nsISupports * 0x03533f20, nsIInputStream * 0x035f115c, unsigned int 0, unsigned int 0) line 427 + 8 bytes nsOnDataAvailableEvent::HandleEvent(nsOnDataAvailableEvent * const 0x035f7e50) line 401 + 47 bytes nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x035f6310) line 97 + 12 bytes PL_HandleEvent(PLEvent * 0x035f6310) line 587 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x0150aa50) line 528 + 9 bytes _md_EventReceiverProc(HWND__ * 0x0b8106b4, unsigned int 49586, unsigned int 0, long 22063696) line 1043 + 9 bytes USER32! 77e71268() 0150aa50()

To reproduce the crash, follow exactly the directions provided by Katsuhiko Momoi on 2000-07-12 23:06 above. Before any changes, I found that it was necessary sometimes to reload the page several times to see the crash.

I followed the steps exactly. After I restart, the browser starts with about:blank. When I click on view menu->Character coding, I see that autodetect is off and western is selected. when I go to to home.netscape.com/ja/index.html it loads. Now if I select, view menu->character coding I see that "autodetect off" is selected and japanese(shift_JIS) is selected and the page loads fine. Is this OK? eric I have attached another fix can you try that too?

Would you try the steps with the Sidebar window open? For some reason, that seems to increase the crash rate.

Radha, your latest patch works for me - the crash is gone (both the original and the new one that your last patch caused) and phonebook draws fine. I followed all the steps above with the sidebar open. (many times)

Ooh, I take that back, I just reproduced the crash again, with the latest patch even.

The crash I just reproduced was the one I gave a stack trace for 2000-07-13 15:41, the new one, not the original one.

In the new crash, nsDocShell::PersistLayoutHistoryState() is requesting the state from the pres shell. The pres shell has one cached so it uses that rather than querying the forms again for one. It addrefs the cached one before handing back. This addref is causing the crash because the cached state has already been released. Is there an extra release of a nsILayoutHistoryState caused by the newest patch?

The original (two line) patch I gave fixes the original crash and does not cause any additional crashes. :) It does not fix the additional, unrelated bug that your patch fixes though. :S (Restoring frame state in phonebook)

Eric, There is actually not much difference between your patch and mine. Your changes are based on the pre-SH_IN_FRAMES functions. Mine takes care of restoring postdata when reloading a page. That's it. I'll play around with possible fixes. However I'm still not able to reproduce the bug.

Right, what I meant to say was that it might be fastest to separate this bug into two parts and deal with them separately 1) Crash on home/ja and phonebook not working 2) Restoring postdata not working for framest pages Then the fix for the first part could be something quick and temporary like the patch I gave, and the final and better solution (the one you are working on) would take 2) into account. This would allow us to close out the nsbeta2+ bugs without delay, and work in the remaining issues later. Of course, this is your bug now, so if you have time to devote to getting it right the first time, by all means, do! :)

I have checked in a possible fix for this. I couldn't confirm that it actually fixed the problem since I couldn't reproduce the problem in the first hand. Hanging on to it until someone verifies that it is indeed fixed.

I tested this in 2000-07-17-08 Win32 build. This still happens. Talkback incident #14351510 Call Stack: (Signature = 0x0b3c6bb2 d5e205dc) 0x0b3c6bb2 nsDocShell::PersistLayoutHistoryState [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 3446] nsDocShell::Embed [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2203] nsWebShell::Embed [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 588] nsDocShell::CreateContentViewer [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2365] nsDSURIContentListener::DoContent [d:\builds\seamonkey\mozilla\docshell\base\nsDSURIContentListener.cpp, line 101] nsDocumentOpenInfo::DispatchContent [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 362] nsDocumentOpenInfo::OnStartRequest [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 234] nsHTTPFinalListener::OnStartRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 1153] InterceptStreamListener::OnStartRequest [d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp, line 1140] nsHTTPServerListener::FinishedResponseHeaders [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 1091] nsHTTPServerListener::OnDataAvailable [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 428] nsOnDataAvailableEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 407] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 106] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 588] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 547] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1045] USER32.dll + 0x1213 (0x77e41213)

The talkback incident before was I used old profile. After I created new profile in 2000-07-17-08 build, this still crash. Talkback incident ID# 14352498 (new profile) Call Stack: (Signature = PresShell::CaptureHistoryState d9f687ff) PresShell::CaptureHistoryState [d:\builds\seamonkey\mozilla\layout\html\base\src\nsPresShell.cpp, line 2968] nsDocShell::PersistLayoutHistoryState [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 3446] nsDocShell::Embed [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2203] nsWebShell::Embed [d:\builds\seamonkey\mozilla\webshell\src\nsWebShell.cpp, line 588] nsDocShell::CreateContentViewer [d:\builds\seamonkey\mozilla\docshell\base\nsDocShell.cpp, line 2365] nsDSURIContentListener::DoContent [d:\builds\seamonkey\mozilla\docshell\base\nsDSURIContentListener.cpp, line 101] nsDocumentOpenInfo::DispatchContent [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 362] nsDocumentOpenInfo::OnStartRequest [d:\builds\seamonkey\mozilla\uriloader\base\nsURILoader.cpp, line 234] nsHTTPFinalListener::OnStartRequest [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 1153] InterceptStreamListener::OnStartRequest [d:\builds\seamonkey\mozilla\netwerk\cache\mgr\nsCachedNetData.cpp, line 1140] nsHTTPServerListener::FinishedResponseHeaders [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 1091] nsHTTPServerListener::OnDataAvailable [d:\builds\seamonkey\mozilla\netwerk\protocol\http\src\nsHTTPResponseListener.cp p, line 428] nsOnDataAvailableEvent::HandleEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 407] nsStreamListenerEvent::HandlePLEvent [d:\builds\seamonkey\mozilla\netwerk\base\src\nsAsyncStreamListener.cpp, line 106] PL_HandleEvent [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 588] PL_ProcessPendingEvents [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 547] _md_EventReceiverProc [d:\builds\seamonkey\mozilla\xpcom\threads\plevent.c, line 1045] USER32.dll + 0x1213 (0x77e41213)

Can somebody else try this. I tried out the latest optimised build off of sweetlou and I did not crash at all. I reloaded atleast 20 times. Went back and forward off of home.netscape.com/ja/index1.html. Had sidebar open/close several times. Even went to the french home page and stayed there for a while and had no luck crashing.

Adding crash keyword

I tried with build 2000-07-18-11-M17 and crashed once out of a couple of tries.

I have checked in the fix that pollmann had suggested in 45288 and worked for this too. Hopefully that will fix this too. Keeping this until someone confirms that the crash is indeed gone.

C'mon, does anyone see this bug happening anymore?!? I'm about one inch away from marking this fixed. :-)

Could not reproduce a crash following Katsushiko's steps using Win32 build 2000-07-19-08-M17. Marking Fixed.

I cannot reproduce this in 2000-07-20-08 Win32 under Winnt 4.0J and Win98J.

Adding keyword to bugs which already show a nsbeta2 triage value in the status whiteboard so the queries don't get screwed up.