Closed
Bug 500232
Opened 16 years ago
Closed 16 years ago
Browser lockup on Vista 64, also other apps lockup afterward
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: xenon, Unassigned)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
This is a very difficult bug because it is impossible to forcibly reproduce in my experience. The problem appeared after updating 3.0.8 to 3.0.10, and persists in the current 3.0.11. In my experience it is dependent on 64-bit Vista running the normal 32-bit Firefox public release. I run the full Vista Aero desktop.
After browsing for long periods of time (usually once or twice a day) Firefox may suddenly lock up and show as (Not Responding). All FF windows will become unavailable when this happens. Firefox may or may not be killable via Task Manager at this point.
Even if Firefox is killed and restarted, some malaise still persists in the system that will cause other apps to start locking up, often while trying to do filesystem access in the vicinity of the user's Windows home directory (IE, saving a file to My Documents from Notepad may jam.)
Shutting down Windows at this point may take several attempts, may take a long time to actually finish the logout/saving user data stage, or may fail to ever shut down at all.
I know the nature of this bug makes it seem like it is NOT caused by Firefox. However, the issue definitively arrived along with FF 3.0.10, and regressing Firefox to 3.0.8 makes the problem go away. I did not test 3.0.9. Switching to other browsers (Chrome) also avoids the problem.
Reproducible: Always
Steps to Reproduce:
Unable to isolate a particular set of steps to reproduce, but problem will _always_ happen given enough time.
Tested using alternate profile and Safe Mode -- problem still exists.
Reporter | ||
Comment 1•16 years ago
|
||
See also, other users reporting what I believe is the same issue here:
http://support.mozilla.com/tiki-view_forum_thread.php?locale=de&forumId=1&comments_parentId=343269
Comment 2•16 years ago
|
||
>I know the nature of this bug makes it seem like it is NOT caused by Firefox
It does't matter if you get this only with Firefox and only with one version of Firefox but the symptoms can not be caused by Firefox, Firefox could only trigger such symptoms. This can not be fixed on our side.
>Firefox may or may not be killable via Task Manager at this point.
That Firefox is sometimes not be killable means that this is a system or driver bug and not a Firefox one.
If the process is gone (killed) you can not get any issues with the system caused by this killed process unless you have a system issue.
marking invalid because this can not be caused or fixed on our side.
If mnore people get this issue you should try to find the driver/hardware that is causing this, for example a broken Third-party Firewall drivers like Zonealarm.
A Firefox hangs/freezes bug only would be valid but you have to do some work, see https://developer.mozilla.org/En/How_to_get_a_stacktrace_for_a_bug_report#Alternative_ways_to_get_a_stacktrace
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 3•16 years ago
|
||
With all due respect, Matthias, I believe you are incorrect.
While it may be true that Firefox by itself cannot be held solely to blame, Firefox can trigger issues in the underlying OS.
The context of this bug suggests it is something specific to Vista 64. 64-bit Windows may not be a 100% perfect environment. However, if FF 3.0.9+ triggers an issue in the underlying OS and previous versions of Firefox do not, normally that would be regarded as a bug in Firefox, at least meriting a workaround to avoid the issue.
As a software developer myself, I know you are faced with a constant stream of false bugs. This is not a false bug.
This system doesn't have any wacky thirdparty stuff like ZoneAlarm or McAffee. It's a development system, and we try to keep them as clean as possible.
I will try to get a stack trace from Windbg.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Comment 4•16 years ago
|
||
>However, if FF 3.0.9+ triggers an issue in the underlying OS and previous
>versions of Firefox do not, normally that would be regarded as a bug in
>Firefox, at least meriting a workaround to avoid the issue.
As all this bugs that are OS/driver/hardware bugs are regarded by the users as Firefox bugs and we get several of such bugs every year.
We do and can not analyze such bugs unless this would be an issue for most 64 bit users which isn't true if I watch the incoming bug reports in the last 2 years. We got for example several reports in a half year about a Zonealarm driver bug that only seem to affect vista (new windows TCP/IP stack).
If you can identify the cause of this and (!) we get many reports about this issue we could probably add a workaround but I don't believe that this will happen. The last workaround that we added was a nvidia driver bug on windows9x that affected all nvidia card users.
Report this to the author of the kernelspace code that seems to hang Firefox if you can not kill the process.
marking invalid again
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago → 16 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 5•16 years ago
|
||
>unless this would be an issue for most 64
bit users which isn't true if I watch the incoming bug reports in the last 2
years.
The bug in question is a new bug, arriving in 3.0.8. I suspect many people who are experiencing it don't yet realize what the cause was, it took me some time to pinpoint the Firefox update as the trigger. There may be people out there now who are simply putting up with weird Firefox crashes and don't know why.
I'll leave this issue alone until I have more definitive evidence in support of it.
https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
when firefox hangs, follow those instructions, and then use:
!analyze -v -hang
attach the log you've created to this bug report.
Reporter | ||
Comment 7•15 years ago
|
||
I wanted to add that I am still tracking this issue, and it persists in recent 3.5.x builds. I have noticed a correlation with visits to ebay.com and am pursuing that line of inquiry to see if I can pin down a particular page or functionality (eg, Javascript) that provokes the problem reliably.
Reporter | ||
Comment 8•15 years ago
|
||
I have not been able to establish any correlation with particular websites. The problem still persists and I am still trying to isolate circumstances that can definitively cause it.
You need to log in
before you can comment on or make changes to this bug.
Description
•