Memory eating at startup

VERIFIED DUPLICATE of bug 54866

Status

Core Graveyard
Profile: Migration
--
critical
VERIFIED DUPLICATE of bug 54866
17 years ago
2 years ago

People

(Reporter: juanjo, Assigned: racham)

Tracking

Trunk
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
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.

Comment 1

17 years ago
did you create a new profile? Sounds like you have an ancient one...

Comment 2

17 years ago
This could be connected to bug 71849.

Comment 3

17 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.
(Reporter)

Comment 4

17 years ago
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 ?

Comment 5

17 years ago
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

17 years ago
worksforme per reporter
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 7

17 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

17 years ago
reassign
Assignee: asa → racham
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: doronr → gbush
(Reporter)

Comment 9

17 years ago
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

17 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

17 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

17 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
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
Last Resolved: 17 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 14

17 years ago
vfy
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.