Open
Bug 670777
Opened 13 years ago
Updated 10 months ago
Firefox hangs when I want to open the Options window
Categories
(Core :: Graphics: ImageLib, defect)
Tracking
()
UNCONFIRMED
People
(Reporter: fletertre, Unassigned)
Details
Attachments
(3 files, 2 obsolete files)
User Agent: Mozilla/4.0 (compatible; MSIE 8.0; PPP v5.1 (1,1,1); Windows NT 5.1; Trident/4.0; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; InfoPath.2; .NET4.0C; .NET4.0E)
Steps to reproduce:
I launch Firefox and tried to open the Options window (Tools menu). Same results if I wnat to save a page, download a file.
Very similar to the Bug 587903 - Firefox hangs on Options "General" tab OR saving files OR "Downloads" (but I don't have Tortoise)
Actual results:
Firefox hangs and I need to kill the process.
Expected results:
The Options window should have been opened or the file should have been downloaded...
I enclose a stacktrace (but not sure it worked properly).
Thanks for your help
Comment 1•13 years ago
|
||
try it with http://support.mozilla.com/en-US/kb/Safe+Mode
For the stacktrace: You forgot the commands at the end, see
https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg
Tahnks Matthias,
Well I forgot to say what I tried before sending this bug:
- launching Firefox in safe mode
- uninstalling (including deleting my profile) and reinstalling Firefox (several times in different version: 3.6.13, 3.6.16, 5.0)
- using ccleaner
- upgrading to DOTNET 4
- desactivating the extensions...
The results stayed the same: Firefox always hang and I had to kill the process.
For the stacktrace, I followed the steps listed in "How to get a stacktrace with WinDbg" but as it hung, Firefox stopped producing logs. So I chose Break from the Debug menu. It didn't stop Firefox and I had to kill the process as usual. When I entered the last few commands (|* ~* kp...), it didn't give any information. What have I done wrong? What should I do?
Regards
François
Comment 3•13 years ago
|
||
>o I chose Break from the Debug menu.
That is right. The Firefox process is now frozen in the current state and ready to debug.
>It didn't stop Firefox and I had to kill the process as usual.
Why do you killed the process ?
>When I entered the last few commands (|* ~* kp...), it didn't give any information.
There is nothing to debug if you already killed the process....
Hi Matthias,
Thanks to your remark, what I didn't understand yesterday became clear, so I run again WinDbg and add the new stacktrace as an attachment.
Ciao
Comment 6•13 years ago
|
||
Does it work if you start windows in the windows safemode ?
That would remove this injected .dll
C:\Program Files\Alwil Software\Avast5\snxhk.dll
No it doesn't.
So I uninstalled Avast (it removed the snxhk.dll file), uninstalled Firefox (including my profile), reinstalled Firefox and tried again. It still didn't work (even in safe mode). I enclosed the new stacktrace but really don't know what to try.
Attachment #545277 -
Attachment is obsolete: true
Comment 9•13 years ago
|
||
I'm not sure but it looks like related to load an icon.
Component: General → ImageLib
Product: Firefox → Core
QA Contact: general → imagelib
Reporter | ||
Comment 10•13 years ago
|
||
What does it mean? Do you know what I could try?
Comment 11•13 years ago
|
||
{
00139c10 781384f9 xul!nsACString_internal::Replace(unsigned int cutStart = 0xc700274c, unsigned int cutLength = 0x100, char * data = 0x01cc419e "--- memory read error at address 0x01cc419e ---", unsigned int length = 0x1240190)+0xc3 [e:\builds\moz2_slave\rel-rel-w32-bld\build\xpcom\string\src\nstsubstring.cpp @ 488]
00139c2c 101d6367 MOZCRT19!arena_dalloc[etc...]
}
If I'm reading that correctly, we're hitting line 488 of nsTSubstring:
> 488 char_traits::copy(mData + cutStart, data, length);
with length = 0x1240190 = 19,136,912
So we're basically trying to set up a string with 19 million characters, to represent the path of a file. That seems bogus.
Comment 12•13 years ago
|
||
This is inside of a call to "GetWindowsFolder", which creates a file-handle for a "special" windows folder (e.g. Desktop, Downloads)
When fletertre hits this problem on the Preferences dialog, I'm guessing the windows special-folder in play might be the default Downloads folder, which is displayed on the General preferences-tab under "Save files to". (And it makes sense that file-save / download manager (both noted in comment 0) would be looking up that same folder.)
fletertre: Are any of your special folders like "Downloads" or your home-directory located in a nonstandard location, like maybe on a network drive or something?
Comment 13•13 years ago
|
||
(In reply to comment #12)
> fletertre: Are any of your special folders like "Downloads" or your
> home-directory located in a nonstandard location, like maybe on a network
> drive or something?
(or alternately, are there any unusual characters in the path to these folders -- e.g. some unicode character in your Windows username -- that we might be tripping over?)
Reporter | ||
Comment 14•13 years ago
|
||
Network drive: I don't think so as my pc is not part of a network. I can't check the actual value of these folders by the preferences dialog through Firefox. Is there anothere way to check the paths to these folders?
Though as I uninstalled several times Firefox, it should be a default value. Besides I think Firefox was set up as to download a file in the last folder used for downloading.
Unusual characters: My username is either "François" or "Francois". I'm not at home so I can't check right now but could the "ç" be a problem. I don't see why as it had worked until a few days ago. Then I also launched Firefox from the Administrator account with the same bug.
Comment 15•13 years ago
|
||
What are your Values of "browser.download.dir"/"browser.download.lastDir" you get of "about:config"?
Reporter | ||
Comment 16•13 years ago
|
||
No such line, the closest I have is browser.download.useDownloadDir;true.
I enclose my prefs.js file.
My username is François.
Reporter | ||
Comment 17•13 years ago
|
||
Updated•2 years ago
|
Severity: normal → S3
Updated•10 months ago
|
Attachment #9383161 -
Attachment is obsolete: true
You need to log in
before you can comment on or make changes to this bug.
Description
•