Closed Bug 192294 Opened 22 years ago Closed 22 years ago

hangs at various URLs (Windows 9x-specific)

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Windows 98
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.3beta

People

(Reporter: contact2009, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: hang, regression, Whiteboard: fixed1.3)

Attachments

(1 file, 2 obsolete files)

v2 patch
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.
I couldn't find any duplicates of this.

This should block 1.3 as it indicates a fairly serious stability problem.
Flags: blocking1.3?
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)
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
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
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
--> 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
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.
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.
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.
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?
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.
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.
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?
Keywords: regression
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.
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]].
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.
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.

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
Flags: blocking1.3b? → blocking1.3b-
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?
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.
this is not zt4new because it is no crash
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?)
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.
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?)
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
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

*** Bug 192341 has been marked as a duplicate of this bug. ***
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.
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.
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

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
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!!
Darin, I tried what you suggested and went to www.netscape.com.  Still hangs.
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. 
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.
Attached patch patch: might help (obsolete) — — Splinter Review 
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.
Attached patch v1 patch (obsolete) — — Splinter Review 
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
Can this make 1.3 beta in time?
Summary: hangs at various URLs (Windows 9x-specific?) → hangs at various URLs (Windows 9x-specific)
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.
Attachment #114064 - Flags: superreview?(bzbarsky)
Attachment #114064 - Flags: review?(dougt)
Flags: blocking1.3? → blocking1.3+
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?
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 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.
*** Bug 192686 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
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.

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.
Attached patch v2 patch — — Splinter Review 
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
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 on attachment 114127 [details] [diff] [review]
v2 patch

r=wtc.
Attachment #114127 - Flags: review?(wtc) → review+
Attachment #114127 - Flags: superreview?(bzbarsky)
Attachment #114127 - Flags: superreview?(bzbarsky) → superreview+
Attachment #114064 - Flags: superreview?(bzbarsky)
Attachment #114064 - Flags: review?(dougt)
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 :-)
Attachment #114127 - Flags: approval1.3?
filed bug 192797 against NSPR.
*** Bug 192799 has been marked as a duplicate of this bug. ***
*** Bug 192809 has been marked as a duplicate of this bug. ***
*** Bug 192912 has been marked as a duplicate of this bug. ***
*** Bug 192954 has been marked as a duplicate of this bug. ***
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+
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! 
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
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 ?
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.
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.
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
*** Bug 193187 has been marked as a duplicate of this bug. ***
*** Bug 193202 has been marked as a duplicate of this bug. ***
*** Bug 193261 has been marked as a duplicate of this bug. ***
*** Bug 193260 has been marked as a duplicate of this bug. ***
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...?)
*** Bug 193292 has been marked as a duplicate of this bug. ***
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
*** Bug 193356 has been marked as a duplicate of this bug. ***
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*
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.)
*** Bug 193431 has been marked as a duplicate of this bug. ***
*** Bug 193476 has been marked as a duplicate of this bug. ***
*** Bug 193482 has been marked as a duplicate of this bug. ***
*** Bug 193510 has been marked as a duplicate of this bug. ***
*** Bug 193449 has been marked as a duplicate of this bug. ***
*** Bug 193620 has been marked as a duplicate of this bug. ***
1.3b 2003021608 installed well, launched well, and is running well (166MHz |
Win95 | 80Meg RAM)
*** Bug 193676 has been marked as a duplicate of this bug. ***
*** Bug 193694 has been marked as a duplicate of this bug. ***
*** Bug 193696 has been marked as a duplicate of this bug. ***
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.
Matteo Settenvini :
with latest build do you mean : the old 1.3b Release or a nightly build ?

a nightly build
Matteo Settenvini, did you install the Mozilla nightly build into an empty
subdirectory?
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.
*** Bug 193945 has been marked as a duplicate of this bug. ***
just confirming comment 92. Slate causes the hang I reported in bug 193945.
*** Bug 193993 has been marked as a duplicate of this bug. ***
*** Bug 194010 has been marked as a duplicate of this bug. ***
*** Bug 194070 has been marked as a duplicate of this bug. ***
*** Bug 194048 has been marked as a duplicate of this bug. ***
*** Bug 194312 has been marked as a duplicate of this bug. ***
*** Bug 194373 has been marked as a duplicate of this bug. ***
*** Bug 194363 has been marked as a duplicate of this bug. ***
*** Bug 192781 has been marked as a duplicate of this bug. ***
*** Bug 194515 has been marked as a duplicate of this bug. ***
*** Bug 194628 has been marked as a duplicate of this bug. ***
*** Bug 194664 has been marked as a duplicate of this bug. ***
*** Bug 194808 has been marked as a duplicate of this bug. ***
*** Bug 194814 has been marked as a duplicate of this bug. ***
*** Bug 194877 has been marked as a duplicate of this bug. ***
*** Bug 194916 has been marked as a duplicate of this bug. ***
I can confirm that since I installed BUILD: 2003022004 the problem has
dissappeared for me. Tested for many days.
*** Bug 194966 has been marked as a duplicate of this bug. ***
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
*** Bug 195118 has been marked as a duplicate of this bug. ***
*** Bug 195159 has been marked as a duplicate of this bug. ***
*** Bug 195204 has been marked as a duplicate of this bug. ***
*** Bug 195276 has been marked as a duplicate of this bug. ***
*** Bug 194467 has been marked as a duplicate of this bug. ***
*** Bug 194577 has been marked as a duplicate of this bug. ***
Whiteboard: landed1.3
*** Bug 195362 has been marked as a duplicate of this bug. ***
Whiteboard: landed1.3 → fixed1.3
*** Bug 195399 has been marked as a duplicate of this bug. ***
*** Bug 195524 has been marked as a duplicate of this bug. ***
*** Bug 195503 has been marked as a duplicate of this bug. ***
*** Bug 195747 has been marked as a duplicate of this bug. ***
*** Bug 195835 has been marked as a duplicate of this bug. ***
Have been running :
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20030225

Problem has not occurred in over a week.
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.
*** Bug 195869 has been marked as a duplicate of this bug. ***
when does the stable Precompiled mozilla be released on windows 98?  


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?)
*** Bug 195907 has been marked as a duplicate of this bug. ***
*** Bug 196118 has been marked as a duplicate of this bug. ***
*** Bug 193149 has been marked as a duplicate of this bug. ***
*** Bug 186368 has been marked as a duplicate of this bug. ***
*** Bug 196255 has been marked as a duplicate of this bug. ***
*** Bug 196431 has been marked as a duplicate of this bug. ***
Tried a final release candidate 2003030405. Works great so far. This is a
win98se now dual-boot with Linux Red Hat 7.3
*** Bug 196586 has been marked as a duplicate of this bug. ***
*** Bug 196617 has been marked as a duplicate of this bug. ***
*** Bug 196710 has been marked as a duplicate of this bug. ***
*** Bug 196679 has been marked as a duplicate of this bug. ***
*** Bug 196936 has been marked as a duplicate of this bug. ***
*** Bug 196939 has been marked as a duplicate of this bug. ***
Component: Browser-General → Networking
*** Bug 197298 has been marked as a duplicate of this bug. ***
*** Bug 197452 has been marked as a duplicate of this bug. ***
*** Bug 196859 has been marked as a duplicate of this bug. ***
*** Bug 199434 has been marked as a duplicate of this bug. ***
This bug is active (build 2003041009 and Windows 95) at least for URL
http://www1.iraqwar.ru/
There is no problem using IE.
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.
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.
> 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. 

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.
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 ---- 
This bug is fixed. You see a different bug if you get hangs with recent builds.

*** 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.

Attachment

General

Creator:
Created:
Updated:
Size: