Closed Bug 71969 Opened 23 years ago Closed 23 years ago

Memory eating at startup

Categories

(Core Graveyard :: Profile: Migration, defect)

x86
Windows 2000
defect
Not set
critical

Tracking

(Not tracked)

VERIFIED DUPLICATE of bug 54866

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...
This could be connected to bug 71849.
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.
worksforme per reporter
Status: UNCONFIRMED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
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 → ---
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.
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
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..?

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
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 ago23 years ago
Resolution: --- → DUPLICATE
vfy
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.