Closed
Bug 192294
Opened 22 years ago
Closed 22 years ago
hangs at various URLs (Windows 9x-specific)
Categories
(Core :: Networking, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.3beta
People
(Reporter: contact2009, Assigned: darin.moz)
References
()
Details
(Keywords: hang, regression, Whiteboard: fixed1.3)
Attachments
(1 file, 2 obsolete files)
1.10 KB,
patch
|
wtc
:
review+
bzbarsky
:
superreview+
asa
:
approval1.3+
|
Details | Diff | Splinter Review |
Using Mozilla 1.3 series 2003020708 on Windows 98, Slate now causes Mozilla to hang. Seems to happen each time. I go there, open 5-6 tabs. Start reading each one, closing the tabs after I finish reading them. Pretty soon, Mozilla stops responding and hangs. Mozilla can then be killed with Ctrl-Alt-Del. This is a recent regression.
Reporter | ||
Comment 1•22 years ago
|
||
I couldn't find any duplicates of this. This should block 1.3 as it indicates a fairly serious stability problem.
Flags: blocking1.3?
Reporter | ||
Comment 2•22 years ago
|
||
The problem does not appear on the same build with a new profile. I also tested it with the old profile after renaming that profile's xul.mfl file. After doing that, I cannot reproduce the problem. Due to the recent nature of the build, there is a possibility that this is an additional testcase for the bug 169777 xul.mfl problems. Will e-mail jrgm@netscape.com a copy of the suspect xul.mfl file. Removing regression keyword.
Keywords: regression
Summary: Open several Slate articles in tabs and it hangs → Open several Slate articles in tabs and it hangs (maybe a xul.mfl problem)
Comment 3•22 years ago
|
||
The XUL.mfl is perfectly well-formed. Moreover, only two top-level documents had been serialized into that file: navigator.xul and commondialog.xul. Given that opening and closing tabs has no dependency on the fastload file (i.e., that will not trigger reading or writing of the fastload file), then I would have to say that this is not a "fastload hang".
Summary: Open several Slate articles in tabs and it hangs (maybe a xul.mfl problem) → Open several Slate articles in tabs and it hangs
Reporter | ||
Comment 4•22 years ago
|
||
Thank you for checking that out. I'm not sure what caused the hangs, but I can't reproduce them anymore. Withdrawing nomination. Resolving worksforme.
Status: NEW → RESOLVED
Closed: 22 years ago
Flags: blocking1.3? → blocking1.3-
Resolution: --- → WORKSFORME
Reporter | ||
Comment 5•22 years ago
|
||
Reopening. I found the problem. It's the history.dat file. When I clear the file, or rename it, the hang goes away. When I put the file back in, the hangs occur. The hangs are not URL-specific, but were especially reproducible on http://slate.msn.com/ . The history.dat file is 968 kilobytes in size. If anyone wants it, I'll e-mail to them.
Status: RESOLVED → REOPENED
Flags: blocking1.3-
Resolution: WORKSFORME → ---
Summary: Open several Slate articles in tabs and it hangs → hangs with large history.dat file
Reporter | ||
Comment 6•22 years ago
|
||
--> History: Global. Reassign.
Assignee: asa → blaker
Status: REOPENED → NEW
Component: Browser-General → History: Global
QA Contact: asa → kasumi
Summary: hangs with large history.dat file → hangs at various URLs with large history.dat in profile
Comment 7•22 years ago
|
||
Yes, please. Send me the history.dat (zip it up first). The size is approximately ok for a heavy web user with a nine day limit on retaining history entries. But something else may be wrong with the file format.
Comment 8•22 years ago
|
||
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030207 hangs. Tested with my all-day-profile ( 1 MB bookmarks, 111 k history, IMAP-mail, pop-mail, news) and tested with a rarely used test profile without bookmarks, mail, news. Size of history.dat in test profile: before test 0 kb, after 2nd hang 4 kb. When mozilla was hanging, I wanted to start Netscape4.8, then all was hanging. After killing mozilla, Netscape came up.
Comment 9•22 years ago
|
||
hangs with fresh created profile. Profile created just for test, nothing changed or specified in profile, went directly to slate.msn.com: - page didn´t load completely until reload. - followed two or three links, hang. I didn´t open anything in new tabs, was just clicking on the left side. history.dat 2 KB, Cache 1,2,3,Map = 7,7,28,132 KB, XUL.mfl 885 KB.
Comment 10•22 years ago
|
||
REGRESSION: seems to be regressed from 2003020608 to 2003020708. I created one fresh profile for all following tests, then tested in this order 2003013104, 2003020308, 2003020608 without seeing hang, then 2003030708 hanging after about 5 links. All tests done only on slate.msn.com. Then I switched to my normal profile, read c´t and inquirer, and when I followed a link from http://www.theinquirer.net/?article=7680 to http://www.heise.de/ct/03/04/024/ mozilla was hanging. (Not repeatable) I could kill an explorer window from the taskbar, but not mozilla. If I try to start a programm ( windows explorer, mozilla ) while mozilla is hanging, windows is hanging too, and the programm is loaded, after mozilla is killed from the task manager (Ctrl-Alt-Del).
Flags: blocking1.3b?
Reporter | ||
Comment 11•22 years ago
|
||
It probably isn't related, but just in case it is, I also have Netscape 4.8 installed. It isn't running when Mozilla hangs.
Reporter | ||
Comment 12•22 years ago
|
||
Again, I really don't know about this, but two bugs relating to the null plugin had check-ins on the 6th: bug 192009 and bug 191021. I have an npul32.dll in Phoenix and Netscape 7 plugin directories. I also have an npnul32.dll in the plugins folder for Netscape 4.8. When I had build 2003020708 installed, there was no npnul32.dll in the mozilla plugins folder. I uninstalled it. I noticed that the plugins directory was not removed by the uninstaller. I then installed the Seamonkey build 2003020804. There is no npnul32.dll in the plugins folder. Not that there is supposed to be, but I'm just observing. Mozilla started. I opened a number of tabs and got another hang. The URL about:plugins does not list an entry for a null plugin, and doesn't list any entries for anything in the Netscape 4.8 plugins folder.
Comment 13•22 years ago
|
||
Andrew, please raise keyword "Regression" again! Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030208 still hanging. Usee my normal profile, started Netscape 4.8 before or after starting mozilla, stated msn in both browsers, followed links in mozilla, read two articles, than hanged, but could browse on with Netscape4.8, also on slate. Killed Mozilla, and started mozilla again to file this posting. Got another hanging following http://www.floriage.com/debut_an.html, found the link at bug 192392, but couldn´t reproduce the hang. One way was, resizing the window from the example in the bug many times, and to have a baseline, I had "About Mozilla" in another window, full size, using the horizontal line from it for orientation. Switched back and forth, multiple times, then hang. I can reproduce the hang with slate.msn.come with a fresh profile, and a win32-talkback.zip into a fresh folder. It doesn´t take more than 4 to five links, thats about 5 minutes. That´s on a system with Celeron333, 96 MB RAM, 8 MB Grafics, Win98 with Servicepack 1 and some security patches, an older version of Zonealarm, a volumecounter, ISDN connection. Will try with phoenix, but don´t have much time. Anybody interested in some files from or the complete profile?
Reporter | ||
Updated•22 years ago
|
Keywords: regression
Comment 14•22 years ago
|
||
Using 2003020804 WindowsME, I get a 100% reproducible hang at both http://slate.msn.com/ and http://www.cnn.com with the following trivial procedure: 1. Go to URL 2. Wait 40-60 seconds 3. Mozilla is not responding, must be killed with "Close Program". I also did a save (Web Page, complete) of the CNN page. Opening this local file has the same hang.
Comment 15•22 years ago
|
||
The history file from Andrew did not appear to have any problems. I'm wondering if this is a case of "getting lucky" when you moved the history.dat earlier (i.e., you somehow avoided the hang for some reason other than moving history.dat). I don't know. The plugin problem is apparently a bug. That npnul32.dll should be in the install and timeless is fixing. Hermann: can you try just copying npnul32.dll from an earlier build (e.g., 02/03) and just dropping it into the Plugins folder in a build from 02/07 on. Can you reproduce this hang in that case? [Note: what happens (from PR logging) when npnul32.dll is not in the current build directory is that npnul32.dll is not processed by nsPluginHostImpl::RegisterPluginMimeTypesWithLayout() [although I don't completely know the implication of that]].
Comment 16•22 years ago
|
||
http://www.microsoft.com/windows/lifecycle.mspx hangs about a minute after loading, status of DUN then shows increase of 16 bytes up/down all 10 seconds. tested Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030209 John, with yesterdays build I had a npnul32.dll in my plugins folder, i renamed it to _npnul32.dll and copied npnul32.dll from Jan,31 . Had same hang, when loading a file from CNN in a tab in the background, had hangs at slate. Today I opened some tabs of microsoft support, and while reading lifecycle mozilla stalled. Didn´t try the others, just retried this one. I tested with fresh created profiles in comments 9 and 10, now I´m using my normal profile because it holds my bookmarks, passwords, mail.
Comment 17•22 years ago
|
||
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030207 Phoenix/0.5 also hanging. I´m doing this tests running mozilla for writing this text and running/hanging/killing/restarting Phoenix for testing websites. Hanging on www.cnn.com, read one article, and when I wanted to return to main page, sandbox was spinning. Instant hang when selecting Resources/Windows Update from Microsoft Windows Family Homepage: http://www.microsoft.com/windows/default.mspx Killed&Restarted Phoenix, opened family homepage twice, to test changing between tabs, was ok, opened Update in a third tab, also ok, copied URL from Update to paste it here, and here this box was frozen. Both Mozilla and Phoenix were frozen. Had three programs in windows taskbar: Windows Explorer, Phoenix, and Mozilla. Changing between these changed the status in the taskbar, but didn´t update the screen for mozilla or phoenix. Only windows Explorer was active. Then I killed Phoenix, and could go on writing here, but the URL copied was lost.
Comment 18•22 years ago
|
||
Mozilla hangs on www.microsoft.com and www.netscape.com, shouldn´t this be a blocker? Running Mozilla to write and Phoenix to hang: http://www.microsoft.com/windows/default.mspx http://windowsupdate.microsoft.com/R1142/v31site/x86/nt4/en/thanksstart.htm http://www.microsoft.com/windows98/downloads/corporate.asp http://www.microsoft.com/windows98/downloads/contents/WURecommended/S_WUNetworking/dun14/Default.asp Loaded first link in Phoenix, and then had some activities in Mozilla. When I wanted to return to Phoenix, Phoenix was hanging. Killed/restarted phoenix, clicked through this 4 links, c&p each of them over here. Read 4th, wanted to save, opened downloadbox, created new folder, clicked ok, file started saving, then Phoenix was hanging. Explorer showed in New Folder only a folder for the HTML-Files belonging to the file to save, but nothing saved. Killed/restarted phoenix, opened 4th URL per cut&paste from here, saved without problems, clicked throug to license, saved, selected language, started to save file after confirming to boxes, then an EXE-file started downloading, but was hanging after 20% of download. Though Phoenix and three download boxes (100/100/20%) are still in the tray, selectable, but not displayed, I can write here ( couldn´t in the comment before ). http://www.microsoft.com/windows98/downloads/contents/wurecommended/s_wunetworking/dun14/license.asp opened 4th URL, clicked license, saved 100%, file arrived complete, but downloadbox hangs. Another website hanging: http://www.netscape.com !!! Went there, did nothing but wait, and change between popups and main page using the windows taskbar. Read about this in Mozillazine, and tested it myself: http://www.mozillazine.org/forums/viewtopic.php?p=42294 My npnul32.dll plugin is version 1, 0, 0, 15
Updated•22 years ago
|
Flags: blocking1.3b? → blocking1.3b-
Comment 19•22 years ago
|
||
This is bug is in the wrong category, it is not a history bug. I can reproduce it consistently with a fresh created profile, see comment 9 and comment 10 It is a regression that came with 20030207, see comment 10 There is no relation to lack of npnul32.dll, because in my zipfiles it´s always the same revision, see comment 16 The browser reproducible hangs at slate.msn.com, at micrososft.com, at netscape.com, and doesn´t give talkback data, so what can I do to avoid this? File a new bug, because this one is the wrong category? http://www.mozillazine.org/forums/viewtopic.php?p=42768&sid=aad4e00a9dbc29e749bc49bb404c97bd#42768 The answer to this comment ( hangs on netscape ) mentions, that he runs Win98SE, and has Tabbrowser Extensions installed. I once tried TBE, just after "Close Other Tabs" had been killed, but id froze my browser. I didn´t do a complete manually reinstall, only killed the TBE.JS or something like that, and the browser was running again. If I´m running on a fresh created profile, with a browser unzipped into a fresh created directory, can that broken install long before creation of this profile have some influence? Is there a difference between running profilemanager from commandline or from inside the browser, because in the second case, another profile is active? I don´t know, wether I installed TBE here on this Win98-machine, or in the office, on a win98SE-machine, but definitely didn´t test TBE on both. Will test in the office today.
Flags: blocking1.3?
Comment 20•22 years ago
|
||
Regression, ZT4NEW? Test at different computer with different OS: bug still there working: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030206 (04-build) hangs: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030207 (04-build) Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030209 (08-build) the computer from previous comments: Celeron 333 with 96 MB RAM, 8 MB noname-Grafics, Win98 with SP1, Patches, ISDN this computer: AMD XP1600 with 512 MB RAM, nForce-Grafics 32 MB, Win98SE, Patches, DSL tested with fresh created profile and directories, just loaded links from previous comments, my only modification: bookmark to bug 192294 in personal toolbar. history.dat 0 kb, XUL.mfl 837 kb, 12 files in cache from 22 to 55 kb.
Comment 21•22 years ago
|
||
this is not zt4new because it is no crash
Reporter | ||
Comment 22•22 years ago
|
||
Back to browser-general for now. Reassign. Updating summary. This appears to be a Win 9x-specific bug. Bug 191021 was resolved fixed yesterday. Not sure yet if today's builds still have the problem reported in here. I'll check as soon as I can.
Assignee: blaker → asa
Component: History: Global → Browser-General
QA Contact: kasumi → asa
Summary: hangs at various URLs with large history.dat in profile → hangs at various URLs (with large history.dat in profile?)
Comment 23•22 years ago
|
||
Last try: downloaded net-installer, went offline, deleted the bin folder where my zips are installed, and started net-installer, changed sugested path from ending in Mozilla to ending in bin, so a fresh folder was created like for my zip-installs. Tested with fresh profile by just loading URLs from my comments, hang. Uninstalled without problems, unzipped build 2003020604 into fresh folder, had to register again as default browser and default mail :-( Last working BuildId: 2003020604 First hanging BuildId: 2003020704 ( Phoenix also hanging ) .. Last tested hanging build: 2003020908 tested with mozilla-win32-talkback.zip and mozilla-win32-installer.exe using virgin program folders and profiles, no addons or prefs changed, whatelse can I do? BTW, I love crashes more, they´ve got the same effects like hangs, i.e. lost updates on bookmarks, but I don´t have to kill the browser myself.
Reporter | ||
Comment 24•22 years ago
|
||
Tested build 2003021008. Still hangs. It doesn't look like this is related to the Null plugin. Bug 192341 is probably a duplicate of this bug. Could somebody test this on NT/2000/XP?
Summary: hangs at various URLs (with large history.dat in profile?) → hangs at various URLs (Windows 9x-specific?)
Assignee | ||
Comment 25•22 years ago
|
||
one of my "fixes" for these two bugs might have caused this regression: bug 191739 bug 192049 my fix for bug 192049 is the most likely candidate. of those experiencing this hang, can anyone test whether or not a loopback network device exists? a quick test would be to execute "ping 172.0.0.1" in a DOS box and see if you get an error or not (error indicating no loopback device). BTW: i'm submitting this comment using the 2003021008 win32 build under win98 with a new profile. reassigning to me :)
Assignee: asa → darin
Reporter | ||
Comment 26•22 years ago
|
||
I ran the following tests on the Windows 98 machine where I have 2003021008 installed. (If it helps, I've got a DSL PPPoE connection.) C:\Windows>ping 172.0.0.1 Pinging 172.0.0.1 with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 172.0.0.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms C:\Windows>ping 127.0.0.1 Pinging 127.0.0.1 with 32 bytes of data: Reply from 127.0.0.1: bytes=32 time<10ms TTL=128 Reply from 127.0.0.1: bytes=32 time<10ms TTL=128 Reply from 127.0.0.1: bytes=32 time<10ms TTL=128 Reply from 127.0.0.1: bytes=32 time<10ms TTL=128 Ping statistics for 127.0.0.1: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
Assignee | ||
Comment 27•22 years ago
|
||
*** Bug 192341 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 28•22 years ago
|
||
andrew: thx for checking 172.0.0.1 and knowing that i really meant 127.0.0.1 ;-) actually, i've been able to repro this hang on win9x with a loopback device present and apparently in use by mozilla (as indicated by netstat). that doesn't rule out the possibility of my "loopback" patch somehow causing this.
Comment 29•22 years ago
|
||
Here I´m running ZoneAlarm, and I´ve got the loopback on 127.0.0.1 4 packets, 0% loss, time < 1 ms With the other computer I´m on a 4 computer network running from a DSL-Router/Switch. Computers are running from Win95 up to Win98SE, the router is a small box, don´t know, if we got loopback there. (router gives addresses to the 4 computers, router got 192.168.1.254, clients got 192.168.1.1 ... 4 ) Today I got a hang while I was downloading the nightlie, while downloading (25 mins) im reading some newsticker, was hanging after 80%. When browser is hanging, all seems to be normal, not vhigh cpu-load or exhausted resources. Looking at the status of DUN, I see 16 byte in each direction about all 10 seconds.
Assignee | ||
Comment 30•22 years ago
|
||
i just experienced the hang a second time. this time i captured a HTTP log, and it does not appear that there was any HTTP activity going on at the time. the hang occured, while i was typing an URL into the URL bar. the URL bar's drop down menu started to appear, and then the app froze. here's the list of candidate checkins: http://makeashorterlink.com/?L27011B63
Assignee | ||
Comment 31•22 years ago
|
||
the last line in my log file is: 0[780070]: nsHttpHandler::Observe [topic="timer-callback")] that executes on the UI/main thread and ends up calling nsSocketTransportService:: PostEvent, which tries to acquire a mutex. it's very likely that we are deadlocking on that mutex somehow, which would result in a zero CPU usage hang.
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.3beta
Assignee | ||
Comment 32•22 years ago
|
||
Andrew, Herman, or anyone else who can readily reproduce this bug: it'd be really great if you could test a recent nightly build using the necko.dll from the 2003-02-06 nightly build. all you have to do is copy the necko.dll from the old mozilla to the newer one and then run with the newer mozilla. if that fixes the hang, then the problem is definitely with my checkins from that time period. thx!!
Comment 33•22 years ago
|
||
Darin, I tried what you suggested and went to www.netscape.com. Still hangs.
Comment 34•22 years ago
|
||
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030210 Tested in fresh folder with normal profile, 9 URLs from here in tabs, hanging after about 8 mins. Then went offline, renamed necko.dll to necko.dll--- and copied necko.dll from Feb,6th-build. Same test for about 30 minutes, no hang. but: my 1st tab is this bug, 2nd and 3rd tab is http://slate.msn.com/, and the first of them didn´t load completely, only after reload.
Reporter | ||
Comment 35•22 years ago
|
||
I can confirm that. I dropped in the file: ftp://ftp.mozilla.org/pub/mozilla/nightly/2003-02-06-08-trunk/mozilla-win32-talkback.zip/bin/components/necko.dll into the installed Seamonkey 2003021008 build on my Windows 98 machine. I couldn't reproduce the hang. Then, I closed Mozilla and changed back to the necko.dll from the February 10 installation. I got Mozilla to hang again.
Assignee | ||
Comment 36•22 years ago
|
||
ok, so then this must be a regression from one of my necko changes. indeed all of the HTTP logs i've been able to capture indicate that this is a deadlock between the nsSocketTransportService::mEventQLock and nsHttpConnectionMgr::mMonitor. i'm not sure how the deadlock is occuring, but this patch eliminates a place where mMonitor is locked while trying to acquire mEventQLock. it might help, or it might just defer the hang. if someone could try this out for me on win9x that would be awesome. it'll be a little while before i get a modified build to test out myself.
Assignee | ||
Comment 37•22 years ago
|
||
actually, i think i found the real problem. my fix for bug 191739, causes us to process the socket transport service's event queue whenever PR_Poll times out. this timeout code was added to make the socket transport service work when the OS doesn't provide a means to implement a pollable event (PR_NewPollableEvent). when we can create a pollable event, we will tell PR_Poll to never timeout; however, it seems like Win9x is not honoring that. as a result, we get blocked calling PR_WaitForPollableEvent while holding mEventQLock. then when the UI thread calls nsSocketTransportService::PostEvent we deadlock trying to acquire mEventQLock. this patch ensures that we don't call PR_WaitForPollableEvent unless PR_Poll told us that the pollable event has been "set".
Attachment #114060 -
Attachment is obsolete: true
Reporter | ||
Comment 38•22 years ago
|
||
Can this make 1.3 beta in time?
Reporter | ||
Updated•22 years ago
|
Summary: hangs at various URLs (Windows 9x-specific?) → hangs at various URLs (Windows 9x-specific)
Assignee | ||
Comment 39•22 years ago
|
||
yup, my hunch from comment #37 was correct. here's output from a debug build w/ socket transport logging enabled: -572169[c3161c]: calling PR_Poll [active=14 idle=0] -572169[c3161c]: PR_Poll timed out -572169[c3161c]: ServiceEventQ: grabbing event queue lock... ... 0[8d4c2c]: nsHttpConnectionMgr::AddTransaction [trans=41e2e24] 0[8d4c2c]: nsSocketTransportService::PostEvent [handler=c930b8 type=1 u=0 v=41e2e24] notice that PR_Poll timed out even though we asked it not to. cc'ing wtc in case he's interested. ok, so i'm confident that my patch is correct. we need to handle a timeout even though we don't expect one.
Assignee | ||
Updated•22 years ago
|
Attachment #114064 -
Flags: superreview?(bzbarsky)
Attachment #114064 -
Flags: review?(dougt)
Updated•22 years ago
|
Flags: blocking1.3? → blocking1.3+
Comment 40•22 years ago
|
||
Comment on attachment 114064 [details] [diff] [review] v1 patch i would love to get wtc to look at changes like this. can you cc him?
Comment 41•22 years ago
|
||
Note that I didn't review the patch because I'm not familiar with the code. If PR_Poll times out even though you ask it not to, that's a serious bug of PR_Poll. Are you sure you are passing PR_INTERVAL_NO_TIMEOUT as the timeout argument to PR_Poll?
Comment 42•22 years ago
|
||
Comment on attachment 114064 [details] [diff] [review] v1 patch If PR_Poll times out (i.e., returns 0), you should not look at any of the out_flags fields of the polling list.
Comment 43•22 years ago
|
||
Comment on attachment 114064 [details] [diff] [review] v1 patch What about comment 42?
Comment 44•22 years ago
|
||
*** Bug 192686 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 45•22 years ago
|
||
yeah, re: comment 42... i was even thinking that i'd pass a parameter to ServiceEventQ stating whether it is being called in response to PR_Poll indicating activity on the "pollable event" or in response to PR_Poll timing out.
Assignee | ||
Comment 46•22 years ago
|
||
wtc: yeah, i'm positive PR_Poll (on Win9x) is timing out even when i pass PR_INTERVAL_NO_TIMEOUT. it doesn't happen consistently, but it does happen :( i'll file a NSPR bug.
Comment 47•22 years ago
|
||
There are a lot of people with Win9x or WinME now downloading 1.3b. Not all of them have a flatrate, or fast broadband access. If this fix is necko.dll only, wouldn´t it be nice, to give these people the possibility to download necko.dll only, only 480 kb, only a minute or two with a slow modem? Necko.dll from Feb6th was working all day for me with current nightly, so I´m rather sure that this will fix it, but comment #33 tells otherwise. I´m asking here, because here are will be decided when this bug is fixed, and here will be known first if a small patch ( = replacing necko.dll only) would be possible. Darin, would necko.dll from 6th of Feb, work in all cases ( Win9x only ), or would the new necko.dll you are producing be better and sufficient, or are more files needed? If more are needed, imho they also can download a nightly.
Assignee | ||
Comment 48•22 years ago
|
||
hermann: necko from 2/6 should be sufficient to get around this bug. of course, you will then get some different regressions. i'm hoping to get a patch for this bug in the tree by end of today so tomorrow's candidate builds for 1.3 final will not have this bug. folks could then be directed to download the nightly instead of 1.3 beta.
Comment 49•22 years ago
|
||
Reply to comment 48: Using a nightly is somewhat more risky for a "end-user", isn't it ? I would rather get a separate necko.dll as suggested in comment 47; Or wish there could be a v1.3b.1 release :-> For the time being, I'll stay with v1.3a.
Reporter | ||
Comment 50•22 years ago
|
||
For most users, installing a nightly in the post-1.3 beta series will be less risky than having them manually install a DLL file. Furthermore, 1.3 final will be out within a short time period.
Assignee | ||
Comment 51•22 years ago
|
||
ok, this patch is better. i've tested it on win98, and experienced 4 unexpected timeouts. with this patch, necko recovered just fine from the unexpected timeouts.
Attachment #114064 -
Attachment is obsolete: true
Assignee | ||
Comment 52•22 years ago
|
||
Comment on attachment 114127 [details] [diff] [review] v2 patch wtc: i'm requesting a review from you on this patch since you suggested it ;-)
Attachment #114127 -
Flags: review?(wtc)
Comment 53•22 years ago
|
||
Comment on attachment 114127 [details] [diff] [review] v2 patch r=wtc.
Attachment #114127 -
Flags: review?(wtc) → review+
Assignee | ||
Updated•22 years ago
|
Attachment #114127 -
Flags: superreview?(bzbarsky)
Updated•22 years ago
|
Attachment #114127 -
Flags: superreview?(bzbarsky) → superreview+
Updated•22 years ago
|
Attachment #114064 -
Flags: superreview?(bzbarsky)
Attachment #114064 -
Flags: review?(dougt)
Comment 54•22 years ago
|
||
Reply to comment 50: My risk was to run into bugs from new ckechins; Your risk is to fail to manually install the .dll file. As the v1.3b is way overdue, it might be simpler to skip it for "us" W9x users. Then, if any of "us" wants to test it before v1.3 release (how soon is it actually expected ?), I'd like to have both possibilities: advice strongly to get a nightly, and make the .dll available for "power users" ;-> PS: We both made our point; I'll now let you work on this bug, and I'll decide what I want to do then :-)
Assignee | ||
Updated•22 years ago
|
Attachment #114127 -
Flags: approval1.3?
Assignee | ||
Comment 55•22 years ago
|
||
filed bug 192797 against NSPR.
Comment 56•22 years ago
|
||
*** Bug 192799 has been marked as a duplicate of this bug. ***
Comment 57•22 years ago
|
||
*** Bug 192809 has been marked as a duplicate of this bug. ***
Comment 58•22 years ago
|
||
*** Bug 192912 has been marked as a duplicate of this bug. ***
Comment 59•22 years ago
|
||
*** Bug 192954 has been marked as a duplicate of this bug. ***
Comment 60•22 years ago
|
||
Comment on attachment 114127 [details] [diff] [review] v2 patch a=asa (on behalf of drivers) for checkin to 1.3 final.
Attachment #114127 -
Flags: approval1.3? → approval1.3+
Comment 61•22 years ago
|
||
I'm about to upgrade to 1.3b - where I can get the replacement Gecko DLL to resolve this problem? I'd really appreciate it if someone could make it available on some web space or something. Thanks in advance - I'd wait for 1.3 final but I'm really desperate for the new features - I've been checking for this release several times a day!
Assignee | ||
Comment 62•22 years ago
|
||
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Comment 63•22 years ago
|
||
I've just tried the nightly dated 13 Feb, and while things are improved, the problem is still occurring AFAICT. Has this been compiled into the nightlies, or is the fix dependent on bug 192797 ?
Comment 64•22 years ago
|
||
I could not reproduce the hang with 2003021304 (the one from latest-trunk directory) on WindoesME. I tried for the better part of two hours.
Comment 65•22 years ago
|
||
Sorry, I was not specific enough - the whole browser does not hang (it can be closed down), but that particular window/tab does hang, and all subsequent attempts at making http connections fail just as before (loading page that never connects). Took me 15 minutes instead of 5 for this to happen.
Assignee | ||
Comment 66•22 years ago
|
||
john: then it sounds to me as if you are seeing a much different bug. this bug was about a hang, that would totally lock up the mozilla UI, forcing you to <ctrl-alt-delete> and explicitly kill mozilla. please file a new bug for the problem you are seeing. thx! marking verified per comment #64
Status: RESOLVED → VERIFIED
Comment 67•22 years ago
|
||
*** Bug 193187 has been marked as a duplicate of this bug. ***
Comment 68•22 years ago
|
||
*** Bug 193202 has been marked as a duplicate of this bug. ***
Comment 69•22 years ago
|
||
*** Bug 193261 has been marked as a duplicate of this bug. ***
Comment 70•22 years ago
|
||
*** Bug 193260 has been marked as a duplicate of this bug. ***
Comment 71•22 years ago
|
||
I'm afraid if this is useful information at this stage, but I could not reproduce the hang with 2003021208(WinME), the one before checkin. (Wierd...?)
Comment 72•22 years ago
|
||
*** Bug 193292 has been marked as a duplicate of this bug. ***
Comment 73•22 years ago
|
||
i downloaded the nightly build Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030213 and my problem on the cnn money site went away - it was previously Bug 193202 and has already been marked as a duplicate in comment #68 - FYI
Comment 74•22 years ago
|
||
*** Bug 193356 has been marked as a duplicate of this bug. ***
Comment 75•22 years ago
|
||
1.3a under Win95 worked for me ... as well as any build. 1.3b talkback stub installer was a dud ... see http://chebucto.ca/Current/AEF/raps/blog/dohh.png 1.3b talkback.zip was worse than a waste ... I blew away my 1.3a install and now get "MOZILLA caused an invalid page fault in module GKGFX.DLL at 0137:61ea217a" before the splashcreen is done loading. *sigh*
Comment 76•22 years ago
|
||
Subsequent to http://bugzilla.mozilla.org/show_bug.cgi?id=192294#c75: I downloaded and installed 1.3a 2002121215 ... everything works fine. Note1: talkback on the corrupt 1.3b worked and at least 1 report was sent Note2: I'm not talking occassional failure to run more than 20 minutes, I'm talking failure to launch and run ... maybe I should file this elsewhere? (On the comical side: the failure forced me back to NS4.8, but the changes in bugzilla form cause it to render dysfunctionally in that venerable old browser ... if I didn't have 1.3a, I couldn't file this report.)
Comment 77•22 years ago
|
||
*** Bug 193431 has been marked as a duplicate of this bug. ***
Comment 78•22 years ago
|
||
*** Bug 193476 has been marked as a duplicate of this bug. ***
Comment 79•22 years ago
|
||
*** Bug 193482 has been marked as a duplicate of this bug. ***
Comment 80•22 years ago
|
||
*** Bug 193510 has been marked as a duplicate of this bug. ***
Comment 81•22 years ago
|
||
*** Bug 193449 has been marked as a duplicate of this bug. ***
Comment 82•22 years ago
|
||
*** Bug 193620 has been marked as a duplicate of this bug. ***
Comment 83•22 years ago
|
||
1.3b 2003021608 installed well, launched well, and is running well (166MHz | Win95 | 80Meg RAM)
Comment 84•22 years ago
|
||
*** Bug 193676 has been marked as a duplicate of this bug. ***
Comment 85•22 years ago
|
||
*** Bug 193694 has been marked as a duplicate of this bug. ***
Comment 86•22 years ago
|
||
*** Bug 193696 has been marked as a duplicate of this bug. ***
Comment 87•22 years ago
|
||
I'm still experiencing these freezes at random. I downloaded the latest build, but now I have re-installed the 1.2.1 because the 1.3b froze once a couple of minutes. It's pretty annoying.... anyone knows why this still happens? I've Win98, but I don't need to open any tab to reproduce this bug... many times it happens when scrolling a page (almost always, horizontally as well as vertically), sometimes compiling a form (rarely). I've to CTRL+ALT+DEL Mozilla! The mouse cursor IMAGE freezes too (I can move it, but it remains always the same icon, for example the insert one, or the hourglass). Please, tell me if it has been fixed, for I downloaded the build Saturday and today it's Tuesday. C'ya.
Comment 88•22 years ago
|
||
Matteo Settenvini : with latest build do you mean : the old 1.3b Release or a nightly build ?
Comment 89•22 years ago
|
||
a nightly build
Reporter | ||
Comment 90•22 years ago
|
||
Matteo Settenvini, did you install the Mozilla nightly build into an empty subdirectory?
Comment 91•22 years ago
|
||
NO, I haven't. I will immediately try. If it works, you can forget my posts, i won't disturb you anymore. Thank you very much.
Comment 92•22 years ago
|
||
*** Bug 193945 has been marked as a duplicate of this bug. ***
Comment 93•22 years ago
|
||
just confirming comment 92. Slate causes the hang I reported in bug 193945.
Comment 94•22 years ago
|
||
*** Bug 193993 has been marked as a duplicate of this bug. ***
Comment 95•22 years ago
|
||
*** Bug 194010 has been marked as a duplicate of this bug. ***
Comment 96•22 years ago
|
||
*** Bug 194070 has been marked as a duplicate of this bug. ***
Comment 97•22 years ago
|
||
*** Bug 194048 has been marked as a duplicate of this bug. ***
Comment 98•22 years ago
|
||
*** Bug 194312 has been marked as a duplicate of this bug. ***
Comment 99•22 years ago
|
||
*** Bug 194373 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 100•22 years ago
|
||
*** Bug 194363 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 101•22 years ago
|
||
*** Bug 192781 has been marked as a duplicate of this bug. ***
Comment 102•22 years ago
|
||
*** Bug 194515 has been marked as a duplicate of this bug. ***
Comment 103•22 years ago
|
||
*** Bug 194628 has been marked as a duplicate of this bug. ***
Comment 104•22 years ago
|
||
*** Bug 194664 has been marked as a duplicate of this bug. ***
Comment 105•22 years ago
|
||
*** Bug 194808 has been marked as a duplicate of this bug. ***
Comment 106•22 years ago
|
||
*** Bug 194814 has been marked as a duplicate of this bug. ***
Comment 107•22 years ago
|
||
*** Bug 194877 has been marked as a duplicate of this bug. ***
Comment 108•22 years ago
|
||
*** Bug 194916 has been marked as a duplicate of this bug. ***
Comment 109•22 years ago
|
||
I can confirm that since I installed BUILD: 2003022004 the problem has dissappeared for me. Tested for many days.
Comment 110•22 years ago
|
||
*** Bug 194966 has been marked as a duplicate of this bug. ***
Comment 111•22 years ago
|
||
Tried 1.3b on Win98SE. Kept getting "This document has no data" and it would generally hang after 5 minutes. Went back to 1.2.1-works well. Very similar to comment 87
Comment 112•22 years ago
|
||
*** Bug 195118 has been marked as a duplicate of this bug. ***
Comment 113•22 years ago
|
||
*** Bug 195159 has been marked as a duplicate of this bug. ***
Comment 114•22 years ago
|
||
*** Bug 195204 has been marked as a duplicate of this bug. ***
Comment 115•22 years ago
|
||
*** Bug 195276 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 116•22 years ago
|
||
*** Bug 194467 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 117•22 years ago
|
||
*** Bug 194577 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Whiteboard: landed1.3
Comment 118•22 years ago
|
||
*** Bug 195362 has been marked as a duplicate of this bug. ***
Updated•22 years ago
|
Whiteboard: landed1.3 → fixed1.3
Comment 119•22 years ago
|
||
*** Bug 195399 has been marked as a duplicate of this bug. ***
Comment 120•22 years ago
|
||
*** Bug 195524 has been marked as a duplicate of this bug. ***
Comment 121•22 years ago
|
||
*** Bug 195503 has been marked as a duplicate of this bug. ***
Comment 122•21 years ago
|
||
*** Bug 195747 has been marked as a duplicate of this bug. ***
Comment 123•21 years ago
|
||
*** Bug 195835 has been marked as a duplicate of this bug. ***
Comment 124•21 years ago
|
||
Have been running : Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030225 Problem has not occurred in over a week.
Comment 125•21 years ago
|
||
I've updated from v1.2.1 to v1.3b ( Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030210 ) yesterday, and I've noticed that Mozilla 1.3b freezes very often on my Windows 98 system, and most of the times it happens when I leave it "unattended": like I open a webpage (or even I open it for the first time, with a local splash page), then I minimize it, and when I need it again say 10-15 minutes later, it's freezed. Sometimes it freezed when I was browsing a website, but it only happened a couple of times. As Comment #124 refers to "Gecko/20030225" as working, I'll try to install a nightly.
Comment 126•21 years ago
|
||
*** Bug 195869 has been marked as a duplicate of this bug. ***
Comment 127•21 years ago
|
||
when does the stable Precompiled mozilla be released on windows 98?
Comment 128•21 years ago
|
||
Valerio: This is a well known problem od 1.3beta. Actually, it is described in the Release Notes. Yu Mo: The recent mozilla1.3 nightlies are pretty stable: http://ftp36.newaol.com/pub/mozilla/nightly/latest-1.3/ Actually, it seems that the final 1.3 release will be the current nightly plus about 6 additional bug fixes (2-3 day from today?)
Comment 129•21 years ago
|
||
*** Bug 195907 has been marked as a duplicate of this bug. ***
Comment 130•21 years ago
|
||
*** Bug 196118 has been marked as a duplicate of this bug. ***
Comment 131•21 years ago
|
||
*** Bug 193149 has been marked as a duplicate of this bug. ***
Comment 132•21 years ago
|
||
*** Bug 186368 has been marked as a duplicate of this bug. ***
Comment 133•21 years ago
|
||
*** Bug 196255 has been marked as a duplicate of this bug. ***
Comment 134•21 years ago
|
||
*** Bug 196431 has been marked as a duplicate of this bug. ***
Comment 135•21 years ago
|
||
Tried a final release candidate 2003030405. Works great so far. This is a win98se now dual-boot with Linux Red Hat 7.3
Comment 136•21 years ago
|
||
*** Bug 196586 has been marked as a duplicate of this bug. ***
Comment 137•21 years ago
|
||
*** Bug 196617 has been marked as a duplicate of this bug. ***
Comment 138•21 years ago
|
||
*** Bug 196710 has been marked as a duplicate of this bug. ***
Comment 139•21 years ago
|
||
*** Bug 196679 has been marked as a duplicate of this bug. ***
Comment 140•21 years ago
|
||
*** Bug 196936 has been marked as a duplicate of this bug. ***
Comment 141•21 years ago
|
||
*** Bug 196939 has been marked as a duplicate of this bug. ***
Comment 142•21 years ago
|
||
*** Bug 197298 has been marked as a duplicate of this bug. ***
Comment 143•21 years ago
|
||
*** Bug 197452 has been marked as a duplicate of this bug. ***
Comment 144•21 years ago
|
||
*** Bug 196859 has been marked as a duplicate of this bug. ***
Comment 145•21 years ago
|
||
*** Bug 199434 has been marked as a duplicate of this bug. ***
Comment 146•21 years ago
|
||
This bug is active (build 2003041009 and Windows 95) at least for URL http://www1.iraqwar.ru/ There is no problem using IE.
Comment 147•21 years ago
|
||
Regarding comment 146: Is it possibly a Win95 only issue. I tried the above link with 1.3 and 1.4a on (the same) Win98SE system ... [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3) Gecko/20030312] [Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030401] ... and got no problem.
Reporter | ||
Comment 148•21 years ago
|
||
Do not post any more comments here. If you are seeing this bug on a recent Mozilla build, then do two things. First, reinstall that recent Mozilla build into a completely empty subdirectory. That should solve the problem. Second, if you are still seeing this problem, open a new bug. Do not post any more comments here.
Comment 149•21 years ago
|
||
> Do not post any more comments here.
Sorry, that is not reasonable. This bug is NOT fixed. I have been getting random
hangs since 1.3b and I am STILL having them with 1.4a. They are NOT tied to any
particular site and they only happen on one of my windows boxen.
I have UNINSTALLED all previous versions and installed 1.4a in a fresh
directory. No other programs hang that machine. Only Mozilla.
Comment 150•21 years ago
|
||
Like the man said. This bug is fixed. Reinstall a recent Mozilla build into a completely empty subdirectory. File a new bug if it's still broken.
Comment 151•21 years ago
|
||
I'm not convinced --- It has been working so-so for me... It still needs work in windows to work right.... It should be left open ----
Comment 152•21 years ago
|
||
This bug is fixed. You see a different bug if you get hangs with recent builds.
Comment 153•21 years ago
|
||
*** Bug 195456 has been marked as a duplicate of this bug. ***
You need to log in
before you can comment on or make changes to this bug.
Description
•