Closed
Bug 491140
Opened 16 years ago
Closed 16 years ago
DNS pre-fetching (bug 453403) freezing Windows XP in Jetico Firewall
Categories
(Core :: Networking, defect)
Tracking
()
VERIFIED
INVALID
People
(Reporter: micha.postbox, Unassigned)
References
()
Details
(Keywords: regression)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090416 Shiretoko/3.5b4pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b4pre) Gecko/20090416 Shiretoko/3.5b4pre
Windows XP is crashing complete with Builds from 20081114 and later + enabled DNS prefetching.
Reproducible: Always
Steps to Reproduce:
1.http://de.wikipedia.org/wiki/Koordinierte_Weltzeit
2.http://shop.ebay.de/items/
3.
Actual Results:
Windows XP is crashing on pages with many links and enabled DNS prefetching.
Expected Results:
No Crash.
since the Build 20081114 Shiretoko (or the old minefield) crashing my win xp totally. Audio stops working, mouse stops working, windows time stops....No automatic restart, no blue screen, no logs, no crashreports.
JIT chrome and content are off. I had it also tested with a clean profile and a new XP installation. Same problem.
First, i have it seen nearly only on ebay.de sites at page load or manually reload, sometimes after 5 Minutes, sometimes after several hours. Later i have found a better site to test this. Wikipedia.de is crashing "almost" always but not allways. The Page loading normaly, Firefox show the state "Done" in the status line and two or three seconds later Windows XP is crashed...Both pages have many links for prefetching...
If Shiretoko can restore the last crashed session, i have often enough seen a immediate new crash and at reboot/next start again and again. So i have to delete the last session manually for a clean Shiretoko start.
The last good nightly was the 20081113 i have it tested over one week without crashes.
Next step was to compiling the firefox self and i cloned the repos to the related changesets for testing.
...
v6 21622:f56d658361cc Crash
v7 21578:bb2c08a5fb4e Crash
v8 21553:60733588d123 ok
v9 21566:5dfdad637696 ok
v10 21572:1c473d3f87ea ok
v11 21575:b765de190a11 ok
v12 21577:0496b58bb9f8 Crash -> Bug 453403. Add DNS prefetching, similar to what Google chrome does. r+sr=bzbarsky, a=beltzner
v13 21576:febe3fb89171 ok
So have found the changeset 0496b58bb9f8 responsible for the xp crashes.
Then i take a official nightly from april and set network.dns.disablePrefetch to true. I have seen no crashes anymore.
Hardware: Asus A7JC with Windows XP
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.5?
Keywords: crash,
regression
Version: unspecified → 3.5 Branch
Comment 1•16 years ago
|
||
I gave this a test in a WinXP VM and on another computer that had a fresh native WinXP install and had no problems.
If it's Windows dying and not Firefox, then it's a Windows bug or a network drivers issue. Though, someone may wish to look into it and see if there's anything that can be worked around here.
Component: General → Networking
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.5?
Keywords: crash
Product: Firefox → Core
QA Contact: general → networking
Summary: DNS pre-fetching (Bugfix 453403) crashed XP → DNS pre-fetching (bug 453403) freezing Windows XP
Version: 3.5 Branch → 1.9.1 Branch
https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
!analyze -v -hang
@timeless
After the crash i can't input !analyze -v -hang to the debugger - system is frozen. And further windows made no memory.dmp or mini.dmp automatically. I have try to enable the rightctrl+ScrLock+ScrLock future to force the memory.dmp manually after the freeze. But this doesn't work, no crash dump...Is it possible to break into the system over a USB/RS232 connection and make a remote debugging session if the target windows is frozen? I'm think also this doesn't work, but i don't know.
kernel debugging is supported over firewire and serial
http://www.wd-3.com/archive/RemoteDbg.htm
if you want to do live kernel debugging, you probably need softice.
Kernel debugging with softice was i good hint. I try a 7 day evaluation version of syser. At debugging start i see NOD32 tcp protection in the output window. Then i provoke the crash with wikipedia sites. To my big suprise after the crash i can switch with ctrl+F12 to the debugger and randomly i discovered that my touchpad work there (usb mouse not). In the debugger i make steps with F10 and can see we are in a loop there. At the bottom in the status line of the debugger window i can read the following line:
fwsrv : hal! KfAcquire SpinLock+0x24
I know that fwsrv is the free Jetico 1.0 personal firewall installed on my system. At next reboot i have deinstalled Jetico 1.0 and installed the good old Kerio 2.15.
I checked again about:config for really enabled DNS prefetching and yes, after 2 hours and many page reloads no frozen windows xp anymore. Testtime is not very long, but it looks good.
In fact this problem is coming up with Bugfix 453403 and enabled DNS prefetching. I dont know who has the blame firefox or jetico, windows, cpu...possible that there are more progs with this effects. The actual Jetico 2.0 i have not tested - its not freeware.
Testcase:
---------
Windows XP + JeticoPFW "1.0" + NOD32 2.7
Provoke the crash with wikipedia sites. Mostly it happen not with the first try. So i use the browser normally for surfing though the web with many tabs. After 20 or 30 minutes i go to the wikipedia tab again and make a page reload...and crash.
please file a bug against Jetico.
softice should be able to give you a stack trace which would be useful for them. feel free to provide it here too.
if jetico provides a reference or url for your bug report, please feel free to list it here.
in short, an error in kernel space is never the fault of a user space application. the kernel driver must handle all input and neither crash nor hang.
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Summary: DNS pre-fetching (bug 453403) freezing Windows XP → DNS pre-fetching (bug 453403) freezing Windows XP in Jetico Firewall
You need to log in
before you can comment on or make changes to this bug.
Description
•