Closed
Bug 71969
Opened 23 years ago
Closed 23 years ago
Memory eating at startup
Categories
(Core Graveyard :: Profile: Migration, defect)
Tracking
(Not tracked)
People
(Reporter: juanjo, Assigned: racham)
Details
From Bugzilla Helper: User-Agent: Mozilla/4.74 [en] (Windows NT 5.0; U) BuildID: 20010214 After start Mozilla, in the initial splash screen, the process mozilla.exe start eating memory by seconds, and the CPU usage comes to 99%. After 2 minutes of showing the splash screen, the memory usage by the process come up to 120Mb and my system comes very unstable. Windows informs that the virtual memory is too low. I must kill the process. Reproducible: Always Steps to Reproduce: 1. Simply start Mozilla Actual Results: I must kill the process or my system comes very unstable. Expected Results: Start Mozilla! I have this problem from Mozilla 0.6, and only after some days of correct Mozilla usage. After some days, Mozilla don't start and only eat memory. Uninstalling and reinstalling don't correct the error. Once start the problem, every Mozilla version is affected. Now, i can't use any version of Mozilla.
did you create a new profile? Sounds like you have an ancient one...
Comment 3•23 years ago
|
||
Do you also have Netscape 6 installed on your box? I too had problems with Mozilla at around the 0.6 timeframe. At that point, I was using just the daily builds. But, I then installed Netscape 6, and Mozilla began to work fine :-/. My guess is that some essential dll or such that Mozilla needed was installed by Netscape 6.
FIXED! Creating a new profile fix the problem. The problem may be the bookmark.html file in the old profile. It was a size of 32Mb!!!. Opening in a text editor, reveals some problems. Some <A> links converted from Netscape 4 bookmark, has the HREF text with lines of about 420.000 strange characters! For example: <DT><A HREF="file:///C|/Mis documentos/DocumentaciÃ?Â?Ã?Â?Ã?Â?Ã?Â?Ã?Â?Ã? ..... .... ica/PHP/index.htm" ADD_DATE="979645776" LAST_VISIT="979898511" LAST_MODIFIED="979645786">PHP4</A>LAST_MODIFIED="979645786">PHP4</A> The problem is the word 'Documentación'. The conversion of the char 'o' with acent generates this trash. This latin char is not correctly converted. Anybody interested in this file ?
Oliver: I don't think, it is connected to bug 71849, since bug 71849 seems to be only with recent builds, while I saw this bug here since several monthes. Since this can destroy the users 1st experience after upgrading from an older browser (eg. Netscape6), this should be investigated in. Any idea? I am not sure, where to put it in, since I am not sure if it is really the bookmark problem (I saw such strange letters before with german umlauts, but Mozilla did work anyway). OTOH, all other components don't look like the culprit either.
Comment 6•23 years ago
|
||
worksforme per reporter
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Comment 7•23 years ago
|
||
reopen and over to profile migration. If we're importing 4.x bookmarks in such a broken state this needs investigation. Reporter, can you try a new profile migration and report back if we are still breaking on that 'Documentación' import.
Status: RESOLVED → UNCONFIRMED
Component: Browser-General → Profile Migration
Resolution: WORKSFORME → ---
Comment 8•23 years ago
|
||
reassign
Assignee: asa → racham
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: doronr → gbush
I've created a new profile. Then, I do bookmark import form Communicator 4.76 bookmark. Still having the same problem, but now is different. ---> Documentación técnica Note that 'técnica' is bad converted too.
Comment 10•23 years ago
|
||
I don't think 'importing' bookmarks is part of migration process. How was this accomplished? Did you just copy the bookmark file into the new profile? Is the bookmark file working in 4.x? Is it getting corrupted during the 'import' process? To remigrate - try removing old profile and registry go to C:\Documents and Settings\<user name>\Application Data\Mozilla\ and remove or rename any files here run mozilla from command line with -installer option (which emulates the command issued after installation completes) - choose to convert and let us know
Assignee | ||
Comment 11•23 years ago
|
||
Only update that happens to bookmarks file during the migration process is renaming bookmark file names on different platforms (Bookmarks.html, bookmark.htm) in 4.x to a uniform name (across all platforms) in mozilla (i.e., bookmarks.html). Naoki & Roy, do you know if we automatically trigger the correct conversion of i18n chars on bookmarks file as we try to load and use the file...? Is this conversion problem due to correcupted 4.x file..? OR due to failure on mozilla front to consume them properly..?
Comment 12•23 years ago
|
||
I am not sure how the conversion is triggered for bookmark or no conversion is done. But I think only one converter would be used (e.g. a converter of file system charset). I don't think multiple convertors are used for bookmark conversion. You can put a break point at nsCharsetConverterManager::GetUnicodeDecoder to see how many time it is called. http://lxr.mozilla.org/seamonkey/source/intl/uconv/src/nsCharsetConverterManager.cpp#501
Comment 13•23 years ago
|
||
This should be a dupe of bug 54866. (Importing ns4 bookmarks does not filter out bad chars. Recursion happens.) Please reopen if you disagree ! *** This bug has been marked as a duplicate of 54866 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Updated•8 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•