From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.1a) Gecko/20020611 BuildID: 2002061104 Running Moz 1.1a under WinME. Computer is often left running unattended. (Mozilla generally not running, but quicklauch is active.) Sometimes this results in all preferences being lost. When I attempt to start mail/news, the "new account" dialog comes up. My prefs.js file has apparently been deleted and replaced with a minimal default version. (File size down to < 2 KB from 24 KB.) Shutting down all moz processes and restoring the file from backup fixes things, although moz still thinks it's being run for the first time when restarted. I'm also running v1.1a on a WinNT computer but have not seen the problem there, so it may be dependant on OS interaction. This may be related to bug 122114. The symptoms are the same, but the trigger is not. Reproducible: Sometimes Steps to Reproduce: This is harder. :( All I've done when the problem has occured is 1. Have 1.1a installed on WinME 2. Have quicklauch running, but no other mozilla components 3. Leave the computer alone for a few hours... Actual Results: Sometimes nothing, sometimes prefs are lost. Expected Results: It should not have deleted my preferences!

I just had the exact same problem running Mozilla 1.1a and also under Windows ME. I lost all my preferences and accounts. Although, when I want into c:\windows\profiles\ and went into Mozilla's application data directory, all the data was still present. This happened to me just after I closed mail and news and reopened it. Quicklanch was active and it was only a matter of seconds between closing Mozilla and reopening it.

This specific error (QL on, idle, losing prefs and accounts etc.) happened to me twice since I installed Mozilla 1.1a. I did not experience this behaviour with 1.0RC2, so I propose adding the regression keyword. I think http://bugzilla.mozilla.org/show_bug.cgi?id=131906 is related, but that bug seems to be the more general case with the same symptoms.

Just had this happen for the first time under WinNT, so it can happen there, it just seems to be rarer.

Confirming bug as new per various comments.

->quickstart

I ran into this on my Win 98 machine at home using Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.0) Gecko/20020621 Netscape/7.0. Very frustrating. My prefs.js was set to a default and even the prefs.bak was trashed, probably because I tried various things to retreive my prefs.js. I *think* I was doing the following when this happened: I was browsing without launching MailNews. I tried to do a 'send page" and was prompted to create a new account! This has been happening lately to a lot of people (Paul Wyskoczka, Gregg Landskov). I have Turbo on.

*** Bug 157208 has been marked as a duplicate of this bug. ***

transferring ADT grafitti from Bug 157208.

Raising the priority of this. At least 5 people have seen this recently. We need to investigate this. Steve or Bill, can you look into this? This appears to be Quick Launch related.

we've had sporadic reports of mail directory prefs getting corrupted, but never found any way of reproducing the problem.

I have set up 2 machines in lab with branch builds from 7/15 or 7/16- to leave idle and hopefully reproduce. Is anyone seeing this on recent builds? Most noted here are Moz 1.0 or NS from June. See also bug 147822

Paul and Gregg, when did you see this? In the dup bug, Varada was using the 7/3 build. Grace, my understanding of this bug is that the app is shut down but quick launch is still running.

I have intermittantly seen this on my Win98 machine only. My Win2000 has not ever exhibited this behavior. It happened as recently as yesterday and as long as 1-2 months ago. I spent some time yesterday uninstalling all versions of mozilla and deleted my mozregistry, mozver.dat files, and all other profile related folders, and started over. In my case, I believe the computer was confused because I had .slt folders in two different locations on the computer and it didn't know which one to point to. I got into this state because I had previously saved my profile folder to a server (so I could keep a copy of my settings in case I lost them!!!). After reinstalling a commercial daily, I pulled my profile down again from the server, presumably in the right place this time. I do not expect this problem to resurface for me again, but will certainly be watching closely.

I have not experienced this bug. I had a problem related to profiles.

This just happened to me this afternoon. I believe it requires only one profile to have it happen (meaning no profile manager comes up when launching). I had used my profile and then exited (with QL on), and did not touch my system for at least 60 minutes. I came back from a lunch meeting and I believe, I could be wrong, but I believe the app was launched and a browser window was up. I clicked on Mail and found the problem (it gave me the Account Wizard instead of launching my existing mail accounts). As a rule, I don't exit the app when I leave for meetings or lunch during the day so that's why I haven't seen this until I purposely exit the app and leave. As a rule, I exit the app and shut down my system before going home, so that's why I haven't seen this with my routine behavior. I will set up a test account and try this again. BTY, my prefs.bak will not help me since it's the same size as the new prefs.js file.

My system is a winxp with 7-15branch build. Trying to recreate now: I just created a new profile and added all my mail accounts back in, copied all my local folders and pop folders to this profiile, copied my bookmark.html, abook.mab and history.mab files into this new profile and then deleted the useless profile so I have only 1 profile. I have launched the app,turned on quick launch and exited. I will wait 60 minutes and check it to see if I can reproduce the problem (oh and this time I have saved my prefs.js before trying this). I'll update when I find out what happens.

Have it reproduced on 2 lab machines WinME and Win95 setup includes: single profile with mail setup and used QL on app exited (all windows closed)=QL still on leave idle for 2- 3 hours -- setup for two additional tests 1. single profile - same as above picture of prefs.js 1. before exit, after exit, before sign on 2. multiple profile - same as above picture of prefs.js 1. before exit, after exit, before sign on (for both profiles)

Esther/Grace - now that you can reproduce this, pls go back one month to a branch build and see if you have the problem. Then, narrow down to the build where this problem started happening. Perhaps that may help in the checkin analysis of what the cause may be so we can get a fix.

This happened to me again on my Win 98 machine at home. This time I had exited out of Netscape. When I returned to my machine, the application had launced itself. When I tried to use Mail, the account wizard prompted me for creating a new account.

At this time we can't reproduce this with exact steps, but we can reproduce it within a 24 hr period on various windows platforms. All we've done so far is to narrow down some criteria for making it happen (Quick Launch=on and single profile) and ruling out what criteria prevents it from happening (multiple profiles and QL off). We're not at a point of narrowing down a specific build but Gayatri's home system has build 6-21branch and I was using 7-15 branch at work. I haven't been able to reproduce it on my winxp with a newly created profile within the last 24 hrs, so it may also be profile creation date related.

See bug 131906 which might be dup of this one.

*** Bug 131002 has been marked as a duplicate of this bug. ***

*** Bug 138309 has been marked as a duplicate of this bug. ***

I'm using the build 2002071408 and Windows 98 SE and I just have discovered this bug. I was using ChatZilla and Mail & News, closed them and some minutes after that I opened again Mail & News and voila!... the profile info (prefs.js) was gone, even in the backup (prefs.bak)! It's all like it was described in the initial comment. QuikLaunch is on and I have a single profile (the default one).

Bug 157922 looks to be related (and may offer a more reproducible scenario).

Per comment 20, it's not profile creation date (existing 6.x prolfiles) related because Grace's test in comment 17 she created new profiles and saw the problem on both.

Adding Brian Nesse to cc: list. Can anybody (Brian, or Conrad) explain when/why we would create a fresh prefs.js file? Given that we can't reproduce this reliably, I'm thinking we may need to just work backward from the code that is overwriting the prefs.js file.

I talked to Brian about this bug and he explained to me how the pref I/O code worked, more or less. We theorized that what might be happening is some sort of conflict between the currently executing instance of Mozilla and the newly started one that QuickLaunch starts up when the last window closes. In order to test this, I added some debugging code to nsPrefService.cpp to log the prefs file I/O, and, to insert 10 second delays between the opening of a prefs file and the writing of it, and between the writing and the closing. I'll attach a patch in a moment that does this. The good news is that this patch enables me to reproduce the symptoms at will. In looking at the log output (here's a portion): 555:##### Opening pref file C:\Documents and Settings\bill\Application Data\Mozi lla\Profiles\Bill\xupq8bxq.slt\prefs.js... 556:##### ...file size=0 557:##### ...input stream created... 558:##### ...openPrefFile rv=0x00000000 559:##### Using user pref file... 560:##### Opening pref file C:\Documents and Settings\bill\Application Data\Mozi lla\Profiles\Bill\xupq8bxq.slt\user.js... 561:##### ...UseUserPrefFile rv=0x80520012 576:##### ...closing... 590:##### ...WritePrefFile rv=0x00000000 you can see that we're seeing a 0 byte prefs.js file, and that this read is occuring precisely while my delay code is blocking the writing of the prefs.js from the original process. Because the code reads an empty prefs.js, it has no user prefs. When the new instance writes out its prefs.js, it writes out exactly the prefs it has, which is none. I have pretty good confidence that this is exactly what's going on in the live code. It will only be a problem with a single profile, because otherwise, the reading of prefs.js is deferred till the user picks a profile on the profile manager window. In such cases, the terminating process will have written them long before that point in time so there will be no conflict. The problem is hard to reproduce because the timing has to be just right to cause the reading of prefs.js in the new process to overlap the writing of prefs.js in the other. This timing would likely be affected by whether Mozilla was active or not (due to system paging characteristics). So the symptoms seem to match this theory pretty well. That said, now all I need is a solution to the problem. Suggestions welcome.

Bill's analysis makes perfect sense. I'm convinced that this would explain the symptoms that have been observed.

Can we do something to the terminating process so that it writes out the prefs before launching the new process?

Note that this problem should also occur without using turbo at all. Suppose the user closed the last browser window by accident and then immediately relaunches the browser.

re: comment 32 Yes, it could happen that way, but this seems so timing dependent that my guess is that it is very unlikely to occur in other circumstances. Plus, there are other mutual exclusion mechanisms used that may make it even more unlikely (e.g., the "MessageWindow" that is closed 'early' during restart). re: comment 31 We could write the prefs earlier, but I'm not sure we could suppress the writing that would also happen later during normal shutdown. But I don't know if the prefs-writing code is clever enough to not re-write if the prefs haven't been modified since last being written. Brian? A related approach might be to "log off" the user profile earlier (before starting the new process). But I don't know if that's possible. Conrad? The various approaches seem to fall into one of these categories: a. mutual exclusion - add some sort of mutual exclusion code so that secondary processes don't read the prefs.js file while we're writing it. That could probably be Win32 specific code inserted locally in nsPrefService.cpp. Or, we could go back to the logic of holding the existing Mutex object for the duration of the restart/shutdown process (see discussion in one of the bugs for which the restart code was the fix for). b. modifying the restart code to avoid the problem - as described above c. something else; one idea is to simply not restart when there's a single profile. Part of the rationale for the restart was to avoid problems with multiple profiles. The only benefit for single-profile users is the side- effect of freeing leaked memory/resources. Maybe that benefit isn't worth it? Another simplistic fix might be to add some sort of command-line switch to the restart that says "sleep for nnnn milliseconds before starting" or something along those lines. I think the criteria should emphasize simplicity and non-riskiness.

re: comment 32 I'd honestly be surprised if this could be reproduced by quitting and re-launching... that window of opportunity is so small, and the user would have to be so fast on the relaunch... re: comment 33 The prefs code doesn't currently have a concept of a persistent dirty state. Although I believe this could be added fairly easily it will likely not help. One of the things that is saved in a preference is the last page visited... which is almost always dirty, and therefore will inevitably cause prefs.js to be written on exit. As prefs need to be loaded as early as possible on launch, we can't do much as far as delaying the read is concerned. I see two options, one is trying to force the write to occur earlier. We currently read in profile startup, and write at app shutdown... we should probably write in profile shutdown for symmetry. Unfortunately, these two things appear to happen almost simultaneously: http://lxr.mozilla.org/seamonkey/source/xpfe/bootstrap/nsAppRunner.cpp#866 The other option would be to try and delay the initiation of the shutdown process until after the save has happened... Or, perhaps, implementing both options would be best.

Here's a proposed fix. It add mutual exclusion code to nsAppRunner.cpp at the points where it reads and writes the pref file. The mutex code is re-used from nsNativeAppSupportWin.cpp where it has already been used to protect win32 startup/shutdown. To make it avaialable to nsAppRunner.cpp, I just separated the declaration and definition and moved the former to nsNativeAppSupport.h. All code (except in nsNativeAppSupportWin.cpp, of course), is wrapped with #ifdef XP_WIN. Some notes: - This works (well, that matters, I suppose). I've got a console log demonstrating as much which I'll add to this bug description a bit later. - There is little risk of the new code being broken, since the meat of it is code that has already been used for years (the Win32 Mutex logic). - The scope of the change seems as limited as possible. - There's a failsafe mechanism built-in: the Lock calls timeout after 30 seconds so worst-case (somebody holds the mutex and never releases it), we resume after a 30 second delay. This timeout can probably be scaled down considerably (I made it 30 seconds to fit with the 20 second delay I inserted into the pref-writing code). I'd think 10 seconds is more than adequate. - The only limitation imposed is the fact that the mutex is of a bit larger scope than it *could* be. We hold the mutex for longer than is absolutely necessary and the coarse-grained nature of the mutex ID (a single mutex name for all Mozilla implementations, for all profile names) means that we're potentially blocking code that doesn't need to be blocked (for instance, saving prefs.js for one profile using Mozilla will block Netscape from reading prefs for some other profile). The scope of the mutex is imposed by the fact that I wanted to put the code somewhere where it could get at the Mutex implementation I already had. I don't think the other issue is worthy of note, since it only has material effect in very unlikely circumstances and has negligible (if any) negative impact regardless.

Here's the console log demonstrating the effectiveness of the code I inserted. What you see here is: a. CreateMutex+Lock for the second process starting up (this mutex name is different than the one I added, BTW) b. CreateMutex+Lock for the first process prior to saving prefs (note mutex name). c. WritePrefFile begins (note countdown), in terminating process d. CreateMutex+Lock for the second process, trying to obtain it prior to initializing the profile. Note that the typical "...wait complete..." message is absent this time! e. WritePrefFile logic completes, at which point it releases the pref file mutex. f. ...wait complete... happens to complete the Lock() request issued by the second process back at point d. g. Second process reads the prefs.js file (which is not 0 bytes, now). CreateMutex error = 0x00000000 Waiting (30000 msec) for mutex: MozillaStartupMutex... ...wait complete, result = 0x00000000, GetLastError=0x00000000 DDE: uType =XTYP_UNREGISTER uFmt =0 hconv =00000000 hsz1 =0000c000:[Mozilla] hsz2 =0001c008:[Mozilla(0X004C0208)] hdata =00000000 dwData1=00000000 dwData2=00000000 DDE result=0 (0x00000000) WARNING: requested removal of nonexistent window , file c:\branch\mozilla\embedding\components\windowwatcher\src\nsWindowWatcher.cpp, line 855 WEBSHELL- = 2 Releasing mutex: MozillaStartupMutex GetPrimaryFrameFor() called while FrameManager is being destroyed! WEBSHELL- = 1 CreateMutex error = 0x00000000 Waiting (30000 msec) for mutex: MozillaPrefFileMutex... ...wait complete, result = 0x00000000, GetLastError=0x00000000 ##### Writing pref file C:\Documents and Settings\bill\Application Data\Mozilla\Profiles\Bill\xupq8bxq.slt\prefs.js... ##### ...backup created... ##### ...output stream created... 10 CreateMutex error = 0x00000000 Waiting (30000 msec) for mutex: MozillaStartupMutex... ...wait complete, result = 0x00000000, GetLastError=0x00000000 Message window = 0x003001A2 DDE server started Releasing mutex: MozillaStartupMutex Type Manifest File: C:\branch\mozilla\dist\WIN32_D.OBJ\bin\components\xpti.dat nsNativeComponentLoader: autoregistering begins. nsNativeComponentLoader: autoregistering succeeded 9 nNCL: registering deferred (0) ##### Opening pref file C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\initpref.js... ##### ...file size=2762 ##### ...input stream created... ##### ...openPrefFile rv=0x00000000 ##### Opening pref file C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\xpinstall.js... ##### ...file size=225 ##### ...input stream created... ##### ...openPrefFile rv=0x00000000 ##### Opening pref file C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\security-prefs.js... ##### ...file size=1410 ##### ...input stream created... ##### ...openPrefFile rv=0x00000000 ##### Opening pref file C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\mdn.js... ##### ...file size=825 ##### ...input stream created... ##### ...openPrefFile rv=0x00000000 ##### Opening pref file C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\mailnews.js... ##### ...file size=22763 ##### ...input stream created... ##### ...openPrefFile rv=0x00000000 ##### Opening pref file C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\inspector.js... ##### ...file size=2085 ##### ...input stream created... ##### ...openPrefFile rv=0x00000000 ##### Opening pref file C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\editor.js... ##### ...file size=3673 ##### ...input stream created... ##### ...openPrefFile rv=0x00000000 ##### Opening pref file C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\config.js... ##### ...file size=2141 ##### ...input stream created... ##### ...openPrefFile rv=0x00000000 ##### Opening pref file C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\all.js... ##### ...file size=34585 ##### ...input stream created... 8 ##### ...openPrefFile rv=0x00000000 ##### Opening pref file C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\debug-developer.js... ##### ...file size=1821 ##### ...input stream created... ##### ...openPrefFile rv=0x00000000 ##### Opening pref file C:\branch\mozilla\dist\WIN32_D.OBJ\bin\defaults\pref\winpref.js... ##### ...file size=8463 ##### ...input stream created... ##### ...openPrefFile rv=0x00000000 CreateMutex error = 0x000000B7 Waiting (30000 msec) for mutex: MozillaPrefFileMutex... 7 6 5 4 3 2 1 ##### ...closing... 10 9 8 7 6 5 4 3 2 1 ##### ...WritePrefFile rv=0x00000000 Releasing mutex: MozillaPrefFileMutex ...wait complete, result = 0x00000000, GetLastError=0x000000B7 ### nsCacheProfilePrefObserver::Observe [topic=xpcom-shutdown data=] ##### Using default pref file ##### Opening pref file C:\Documents and Settings\bill\Application Data\Mozilla\Profiles\Bill\xupq8bxq.slt\prefs.js... ##### ...file size=845 nsPluginHostImpl::Observe "xpcom-shutdown" ##### ...input stream created... ##### ...openPrefFile rv=0x00000000 ##### Using user pref file... ##### Opening pref file C:\Documents and Settings\bill\Application Data\Mozilla\Profiles\Bill\xupq8bxq.slt\user.js... ##### ...UseUserPrefFile rv=0x80520012

Steve and/or Conrad, can you review this fix, please? I'll need a sr= also (in case any are watching). I'm on my way in to the office and should be there shortly. BTW, I think this fix should be branch-only. There is code on the trunk that provides some protection against re-using profiles and I'm not sure how this code co-exists with that.

Comment on attachment 91997 [details] [diff] [review] Proposed fix r=morse

Comment on attachment 91997 [details] [diff] [review] Proposed fix sr=bryner

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending drivers' approval. pls check this in to the 1.0 branch, then replace "mozilla1.0.1+" with "fixed1.0.1". thanks!

law: when do you believe you can land this?

I believe I can land this real soon now (in a few minutes).

When I checked this in, I said sr=jag. It was, of course, sr=bryner. Thanks, Brian.

Law, we'll need something for the trunk soon. We can release note this for 1.1beta but final (early next month) will need a fix.

Perhaps this is a completely irrelevant point at this stage, but it seemed worth mentioning. # Redundant backup of preferences files has been implemented in 1.1 Alpha. - From 1.1a release notes

*** Bug 156878 has been marked as a duplicate of this bug. ***

*** Bug 158845 has been marked as a duplicate of this bug. ***

Using the steps I used last week to reproduce this bug- and branch build for 7/22, I do not see the problems I did (bug 157922) waiting for results of testing by folks who experienced this regularly before marking verified

I need to re-open this bug in the branch so I am removing the fixed1.0.1 keyword. I am still experiencing the problem using the 7/22 branch build. I opened and closed Netscape about 3 times and my preferences disappeared. I think this problem is easier to reproduce on my slow Win 98 machine at home rather than on the faster machines at work.

from reporter of bug 158845 I´m trying it on 2002072308 and I didn´t lost all pref, but first I lost the mail accounts passwords and after that I lost the master password (and I know I didn´t change it)

ARGH! I just ran into this bug again today as well. I am running 20020723 on Win98, Turbo Mode ON, Single Profile. I did not lose my bookmarks (consistent with previous instances), but did lose all my Mail settings, my AIM setup, my password manager info, my form info, etc.

Gregg, Gayatri (and anybody else witnessing this bug): Can you have a look at your Profiles directories and see if there's any evidence that we've created a brand new profile (and sub-directory with salted name)? These would be located somewhere like c:\Documents and Settings\<username>\Application Data\Mozilla\Profiles". If you go to that directory and enter something like "dir /s /b *.slt" the output would be of interest. The theory is that this bug involves processes simultaneously writing/reading the registry.dat file (my previous attempt at fixing this only protected the reading/writing of prefs.js). I'm trying to force that scenario to see if it produces the symptoms, but without success so far.

In my case a new profile was not created. Also, in case it helps, my laptop is a 500 - 600 MHZ machine with 128M RAM.

There is only one *.slt folder on my machine, I believe it is the same name I had before. It still contains *some* of my originial files like bookmarks, and it looks like my cache folder still has lots of files in it. So I don't expect that it created anything new. My prefs.js file is really small as expected.

OK, thanks for the info. I've programmatically caused the registry.dat I/O to overlap but it doesn't seem to produce any ill effects whatsoever. So it doesn't look like that's the problem. Nobody can come up with a theory as to how/why *multiple* files can get lost. We know single files are subject to problems (as demonstrated with prefs.js) but it would seem very unlikely that this could cause numerous files to all get wiped out at the same time. Perhaps it's something in the profile code...anybody out there with any clues on what might be going on there?

I have a profile in our lab on a dial up win98 system that I can reproduce this within 5 minutes. I have simplified the steps but not narrowed them down yet. I use the same profile after it has edited the prefs.js file by deleting the bad prefs.js and copying the good prefs.js file back into the .slt directory. Then I: 1.)Launch app by right mouse click on desktop icon and selecting Open (I don't think this specific way of opening it is necessary other than possible timing) NOTE: I have a screen name entered in my buddy list, with no password saved nor signon launch selected. I did this so I can see when the problem happens without opening mail. 2.) While launching I watch to see if it shows my buddy name in the AIM section, if no buddy name then the prefs.js file has been wiped out. 2.)File|Exit after I see the screen name indicating the prefs.js file is still OK. 3.)Repeat step 1-3 again, rather quickly and sometimes multiple times until the app finally launches. Result: Eventually you will see that you AIM setup is no longer there (I can get to this point with this system and profile within 5 minutes), this means your mail accounts and other prefs have been erased and a new prefs.js file was created. I'm working on this some more to see if any particular action causes this. This is all I can offer at this time. I did not see multiple .slt directories or profiles. I did take a snapshot of the directory structure right before and after. I can attach them to this bug after I make sure they don't contain system information.

Esther, it doesn't look as if you're using QuickLaunch, then?

I talked to Esther and witnessed the phenomenom first-hand. To answer my own question (about QuickLaunch): Yes, she did have QuickLaunch on. In addition to the process QuickLaunch shutdown was launching, she was launching additional processes. Coincidentally, Steve Morse and I detected a very narrow hole in the defenses against simultaneous reading/writing of prefs.js that I implemented over the weekend. It happens that this hole would require use of an additional process to send another request at a particular point in time. This is because the trigger for reading prefs.js can be hit from another location that is not protected by the mutex code I inserted. I am in the process of plugging that hole. I will do an optimized build and deliver it to Esther overnight for testing on the machine in question tomorrow morning. *If* that fixes the problem there, then the only remaining question is whether the additional occurrences of the bug (since the landing of the previous fix for this bug in Monday's build) *all* involved the same scenario: QL on, user double clicks the program icon while QL is doing its restart. Esther thought that Gayatri maybe had done that. I'm not sure about Gregg.

Yes, that is my scenario: QL on, select Netscape, right click on mouse and select Open while QL is doing its restart.

This is the patch for the code I modified. A .zip file with this patch included will be delivered (via email) shortly. Keeping my fingers crossed...

Comment on attachment 92866 [details] [diff] [review] Additional patch that adds Mutex lock around DoProfileStartup on alternate code path r=morse

Reports from QA are that the build with the attached patch does fix the problem of the disappearing prefs.js (on the one machine where we could reliably reproduce the problem). There are still some negative results however. Double-clicking the program icon while QL is restarting results in browser windows opening that are 'broken' in various respects (distorted or missing content, drawing problems, etc.). Those issues seem to be much less severe and given that the problems are only evident in relatively obscure cases, my assessment is that the remaining problems are not necessary to fix for Mozilla 1.0.x or NS7. My proposal is that we go with this additional patch, on the branch only. We can work towards fixing the general problem (two instances simultaneously running) properly on the Mozilla trunk (the issues are slightly different there due to the landing of the profile-locking code). Any comments?

Comment on attachment 92866 [details] [diff] [review] Additional patch that adds Mutex lock around DoProfileStartup on alternate code path sr=bryner

Me too. My mail accounts and preferences were all clobbered just a couple days ago within minutes of installing 1.1 over my 1.0 milestone install. Really sucked. I'm on Win98 Second Edition 4.10.2222 A I'd like to ask if creating additional profile(s) has been confirmed as a successful means of circumventing this issue?

Tommy, in all of our cases here having more than 1 profile does circumvent the problem.

Here are the specific side issues I saw when testing Bill's patch on 7-26: If I click on the N desktop icon several times starting before the N appears in the task bar at the bottom of the page, I will get several brower pages loaded, when the app finally opens. * The front most browser page is garbbled at first and takes about 20 seconds to finish displaying but it completly displays. * The second and third browser pages that opened in the back are missing the sidebar content and stay that way until the user clicks View|Show/Hide/My Sidebar. I tried the sidebar tab to show/hide but that didn't appear to do anything (could be a bug not related to this). If I click on the N desktop icon several times starting after the N appears in the task bar at the bottom of the page, I may get several brower pages loaded when the app finally opens or I may get only 1 (must be a timing thing) * All the browser pages that launch are OK.

The scenario Esther describes sounds like an edgecase, and is less severe then losing your prefs, let's get this checked into the branch so we can pound on it. adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending Drivers' approval. pls check this in asap, then chang "fixed1.0.1" to "verified1.0.1".

please checkin to the 1.0.1 branch. once there, remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.

fixed, again

*** Bug 160005 has been marked as a duplicate of this bug. ***

Why is this bug resolved? I don't see any indication that this was fixed on the trunk.

I took the 7-30 branch build, installed it over the build without the fix and I can still see the last reported problem (hitting the N button on the desktop rapidly before the N appears in the task bar). I can lose my prefs.js file almost every time I do this with the new build. Did this fix get in.

re: comment 71 I wanted to indicate that it's been fixed on the branch. It isn't clear that this is even a problem on the trunk (where there is additional profile-locking code now). We can re-open it (which might happen anyway since there's now the report that says it isn't fixed on the branch). re: comment 72 Yes, this fix went in (on 7/29, so it is in the 7/30 build). Crap. I have no idea why it doesn't work now.

Bill, it appears to continue happening when you install the fixed build over the buggy build. When I installed the fixed build into a new directory, I can't reproduce the prefs.js file being wiped out. However, I think most people will install over the top of an existing build.

re: comment 73 (response to comment 71) Unless I'm misreading the roadmap, this bug was opened against the trunk. Either way, it's still present in 1.1beta (2002072104). I haven't tried a more recent nightly because I've seen no indication of this being fixed there.

Further testing shows that this still happens on builds installed in a new directory or over the top of an existing build. Also, I tested more like a user would by Exiting, waiting for the icon to appear in the task bar then double clicking on the desktop icon (not hitting the button quickly and continuously). and then double clicking again due to the app not launching the first time. We ran into the problem, so this is not fixed yet. Bill is looking into this.

Reopening as QA is still able to reproduce this in their lab. :-(

FYI: I sent Esther a build last night that had another fix. I tweaked the QuickLaunch restart logic so that it suppressed the shutdown and restart if the user had only one profile. That avoids the simultaneous shutdown/restart scenario that seems to trigger the occurrence of this bug. Esther reports that this seems to fix the problem on the machine where she had been able to reproduce it. It also avoids the incidental problem of bogus Navigator windows opening if you clicked on the program icon while QL was shutting down and restarting. I'm not sure exactly where we stand/stood with respect to *requiring* the restart in the single-profile case. Does anybody know if eliminating the restart will have any negative consequences other than the accumulation of leaked memory over time? Are there any password manager, security, etc. issues that could arise?

Bill, half of the bugs reported here (this bug plus the 5 duplicates) are against the trunk. Based on that admittedly small sample it looks like this also has a definite impact on trunk build users.

*** Bug 160522 has been marked as a duplicate of this bug. ***

More FYI: We abandoned the strategy of not doing shutdown/restart in the single profile case. There are/were too many bugs relating to properly releasing profile-related resources when the last window closed. Those are all resolved by doing the shutdown/restart and we didn't want to have to deal with all those bugs until we could find no alternative. So, after lengthy discussion with Conrad, we decided that the saving of the prefs.js should occur before we shutdown the profile. That way, prefs.js is protected by the profile lock (that is in place on the trunk). It also changes the performance characteristics (or so I theorize) so that this seems to fix the problem with lost prefs.js files on the branch, also. Esther is testing that more thoroughly. I will attach the patch that moves the saving of prefs.js in just a second... P.S. This latest patch will definitely help on the trunk. We'll need somebody to test whether it fixes the problem entirely (or as best as can be determined). Can anybody reproduce this consistently with trunk builds? I'll leave the bug open till we've resolved the issue across the board.

This one is OK for branch and trunk.

One more data point... I just uninstalled a daily branch build from Tuesday and then installed today's branch build - 20020801 - (Win98, single profile, Turbo on), and the same thing happened, prefs.js mostly wiped out.

I finished testing the patch I receive from Bill (15508020020731.1430.zip) I received last evening. I tested it by consistanly clicking the desktop icon before the tray icon appeared (impatiently). I tested it by double-clicking the desktop icon after the tray icon appeared, waiting several seconds between double-clicks (patiently) until the app launched. These tests were done for Single profile and multiple profiles. I could not break the prefs.js file. I also tested it by Exiting the app and leaving it alone for an hour then launching again (this was one of the original scenarios). This can be checked in now.

varada@netscape.com, charleshixsn@earthlink.net, dellacasae@alma.it, rbeldin@atl.hp.com, srayzen@netscape.net, t3xt3x@inwind.it and mjcarman@mchsi.com, you all were experiencing this problem and a fix is about to land on the Mozilla trunk. As soon as we have builds with that fix (the morning after the fix lands) can you please get a build and test this to make sure it works as expected? The more testing we can get on this the better for 1.1 and 1.0.1. Thanks.

I have consistenly reproduced this on the trunk build on the same system in the lab I have been using for branch builds. I can help verify this when it gets checked into the trunk.

Comment on attachment 93601 [details] [diff] [review] Patch that moves SavePrefFile call ahead of DoProfileShutdown sr=bryner, but please test that this won't cause the profile manager to appear due to a locked profile.

Comment on attachment 93601 [details] [diff] [review] Patch that moves SavePrefFile call ahead of DoProfileShutdown r=ccarlen. Ensuring that the prefs are written within the scope of a profile lock is a good thing. Looked for other users of profile data and didn't find any. The lock has been around on branch & trunk since mozilla1.0.

Comment on attachment 93601 [details] [diff] [review] Patch that moves SavePrefFile call ahead of DoProfileShutdown a=asa (on behalf of drivers) for checkin to 1.1. Let's get this in as quickly as possible so we can get some testing before we ship 1.1. Thanks , law, for the fix and thanks esther for the testing.

OK, I'm going to check this in now on the branch. I'm currently doing a trunk build to make sure that the timing differences don't have any negative impact there (wouldn't that be just our luck). Once I've verified that it works OK there, then I'll check it in on the trunk.

adt1.0.1+ (on ADT's behalf) approval for checkin to the 1.0 branch, pending Drivers' approval. pls check this in asap, then change "mozilla1.0.1+" to "fixed1.0.1". thanks!

fix in on trunk and branch Marking fixed, changing keyword

*** Bug 156015 has been marked as a duplicate of this bug. ***

gbush/esther: can you pls verify this as fixed on the 1.0 branch, and trunk, then replace "fixed1.0.1" to "verified1.0.1"? thanks!

*** Bug 160522 has been marked as a duplicate of this bug. ***

I took the trunk build this morning and the ug appears to be fixed. I spent an hour trying to break the prefs.js file with a single profile scenario (the same one I could break last night within 3 minutes). Clicking rapidly on the desktop icon and then being a little more patient. One thing I did notice with the trunk that did not happen with the branch is the AIM setup is not read in alternate launches when I run thru this test. The reason I mention this is because that was usually the sign that my prefs.js file had been edited when running my scenario and I thought that was a pre-warining that this bug would happen eventually. That doesn't seem to be the case with the build with the fix. I still lose the AIM setup alternately, but the prefs.js file does not get rewritten. Grace will test that scenario and log a new bug in bugscape. So the trunk appears to be OK now. Now I will test the branch build.

Testing the am 8-2 branch build, I still see the bug. Are you sure this went into a branch build for 8-2 am. I'm going back to the lab to make sure I didn't take the wrong build.

The purported fix definitely went in on the branch (rev 1.345.2.11). If I heard Conrad right, the profile locking code *is* in effect on the branch. If that's the case, then I cannot figure out how we're bumping into problems involving contention over pref-related files. I'm not sure exactly how the profile-locking is accomplished. Is it possible that there's something subtle about the way we're launching the restarted QL process that causes this locking code to break down? I'm thinking specifically about the fact that this process appears to run as a child process of the original process. Perhaps that means that it inherits some file handles or access privilege that bypasses the profile lock?

I have a Win 98 machine that I can reproduce this on now- using Esther's profile set up. I am seeing it on the branch build after about 6 or 7 launches.

Hmmm. I wonder if the fact that we only see it on Win98 offers a clue. Maybe there's something different about the profile-locking implementation on Win98?

We're pretty much at a complete loss on this one. What I think I need to do next is revisit investigating exactly what is going on in the cases where it fails. We can't come up with any plausible explanation as to how it could still be failing in the manner we first diagnosed. To do that, I need to insert some logging code and perhaps also some code that alerts us if we run into particular situations (e.g., a zero-length prefs.js file). That has to be done in an optimized branch build and then executed on a machine where we can reproduce the problem. Then, we'll look at the output and assess what has occurred and figure out a way to prevent it. I'm concentrating on the prefs.js I/O code initially. I could use some help inserting appropriate logging code into the profile manager code as well. I can have a test build ready to run Monday morning. Hope that sounds like a plan, 'cause it's the best I can come up with at this point.

Just a few thoughts from someone who adds diagnostic code to isolate intermittent problems. It might be useful to step outside the program and see if noticing when the opens/reads/writes/closes are being made to the prefs.js and correlate them to specific diagnostic messages that Mozilla generates. On HP-UX, I use a tool called tusc or trace that will trace all system calls and timestamp when they occur. You can then match up raw system calls to code that may be somewhat abstracted within the application. It might catch some area of the code that we don't think is executing. I don't know if there anything like this under Win98, but there might be something under NT, 2000, or XP. Just a thought. Another thought is to provide some sort of crude workaround while root cause is being find. My thoughts are to checkpoint the existing prefs.js periodically during the execution of the program. While this might be done externally via script (multiple platforms cause problems) it might be best to do this within the program itself. Perhaps every so often Mozilla would validate the cksum and size of the on-disk prefs.js against what it started with and noticing a 'difference' might put us closer to where the problem is occurring. It also would provide a crude mechanism for the user to have a backup of the prefs.js. I do this manually with a copy of prefs.js right now, only I only notice the difference in prefs.js when I start up Mozilla and find all my customizations have dissappeared. :-( I'll be willing to test on a WinXP and WinNT platform.

Reopening per Comment #99 From Grace Bush. Removing fixed1.0.1.

there is the freeware "filemon" http://sysinternals.com/ntw2k/source/filemon.shtml

Grace, are you reproducing this on the trunk with win98? Any other OS?

I did not see this on trunk build (commercial) for 8/2 but did see in branch, since then I have been testing on test builds

Asa, I just spoke with Grace, we want to make sure we are clear on this. Grace did see this with a trunk build before the fix on 8-1. We both could reproduce it with my sceario on 2 different win 98 systems with both branch and trunk. After the 8-1 fix that went into the branch and trunk, neither of us could reproduce it on those same systems for the trunk build. However we still saw the problem with the branch builds. Bill is still looking at this.

OK, this patch fixes a problem whereby we could be fetching a pref value before the profile is initialized. This could happen if a request comes in from a third process while the QuickLaunch shutdown/restart is in progress. Since the pref being tested is set true in all.js and there is no UI to change it, 'hardoding' it so that true is implicit doesn't cost anything. The code being protected hasn't caused any difficulties. Rearrangement of the logic could leave the pref test in place, but I'd rather not deal with more significant changes at this time due to the increased risk of doing so.

Comment on attachment 94272 [details] [diff] [review] The final patch, no matter what, I swear Bill explained this to me and this seems like the correct fix. r=caillon.

Comment on attachment 94272 [details] [diff] [review] The final patch, no matter what, I swear sr=blake

Comment on attachment 94272 [details] [diff] [review] The final patch, no matter what, I swear a=asa (on behalf of drivers) for checkin to 1.0 branch

adt1.0.1+, per verbal approval from Jaime, which I've changed to fixed1.0.1 Fix landed, QA has tested this fix in a one-off build today, will verify with tomorrow's build

grace/esther: pls verify this as fixed in tomorrow's branch build. thanks!

*** Bug 161447 has been marked as a duplicate of this bug. ***

Bill, if you've hardcoded a pref from all.js as 'true', shouldn't that pref be removed from all.js ?

re: comment 115 Yes, that was part of the patch.

I have been testing this for 20 minute stretches- I cannot break it- left it for awhile to see if the 'unused' symptom would cause a problem. Looks good - 8/7 branch

reopening and removing fixed1.0.1 I can reproduce this on my system and I also could reproduce it on Grace's system. We informed Bill, he found the cause.

It turns out that that last remaining hole was in AIM code. It was writing out prefs.js at application shutdown, which is after the profile is unlocked (and not protected with the mutex code I added to nsAppRunner.cpp). That's going to require changes to the AIM code, which in turn requires a Bugscape bug: 18921 (http://bugscape/show_bug.cgi?id=18921). I think we should close this one and transfer our (Netscape's) attention to the bugscape bug. In retrospect, moving the writing of prefs.js within the profile lock fixes this problem for Mozilla builds. The bug is only present in Netscape distributions (branch and trunk, although I'm not sure we've reproduced on the trunk).

gbush/esther: pls verify this as fixed on the 1.0 branch and trunk. As noted in Comment #119 From Bill Law, the one remaining issue will be dealt with in Bugscape bug: 18921 (http://bugscape/show_bug.cgi?id=18921).

OK, I'll retest this on branch without AIM activated in Side bar. As I understand, it's not necessary to Install the app without AIM to test this. Bill correct me if I'm wrong. I will then test the trunk again with a latest build just to be sure the fix that went into the trunk on 8-2.

I tested the branch and trunk again. Without the Sidebar open, both branch and trunk are OK. With Sidebar open, the Address Book and Shopping tab active I could wipe out the prefs.js file with a slightly differenet scenario on the trunk (I did not check the branch). Bill believes this is the same problem with AIM as noted in bugscape bug 18921 due to the Address book being active in sidebar and possibly the interaction AIM has with mail and the Address book. So I retested with Sidebar closed and could not reproduce the problem. I will verify this as fixed. I will test this new scenario with the bugscape bug fix.

I saw the same sympton today on Solaris 8 Sparc (bug 162550). I thought quicklaunch is Windows only ? Or is there another problem hidden behind both bugs ?

Did the final patch checked into 1.0.1 also reach 1.1 ?

*** Bug 162552 has been marked as a duplicate of this bug. ***

*** Bug 162541 has been marked as a duplicate of this bug. ***

"savemozprefs" is a Perl script runs on windows as well as other platforms so long as Perl is installed. It exists to back up mozilla profile directories and preferences. It is accompanied by another script called "restoremozprefs.pl" which restores files which were previously backed up by "savemozprefs.pl"

"savemozprefs" is a Perl script runs on windows as well as other platforms so long as Perl is installed. It exists to back up mozilla profile directories and preferences. It is accompanied by another script called "restoremozprefs.pl" which restores files which were previously backed up by "savemozprefs.pl" I've uploaded this file to help those who test Mozilla builds with the problem described in this bug (#155080). -- -Tommy Butler see if I'm online »http://ooopps.sourceforge.net/online Tommy Butler <tommy@atrixnet.com> phone: (817)-468-7716 6711 Forest Park Dr Arlington, TX 76001-8403 Download my résumé in PDF, MS Word, HTML, text http://www.atrixnet.com/ the open source ooOPps Code Library (programs, scripts, code, tutorials) http://ooopps.sourceforge.net/pub/

"restoremozprefs.pl" is a Perl script runs on windows as well as other platforms so long as Perl is installed. It exists to restore mozilla profile directories and preferences from back up. It is accompanied by another script called "savemozprefs.pl" which performs back ups on files which can later be restored by using this script, "restoremozprefs.pl" I've uploaded this file to help those who test Mozilla builds with the problem described in this bug (#155080). -- -Tommy Butler see if I'm online »http://ooopps.sourceforge.net/online Tommy Butler <tommy@atrixnet.com> phone: (817)-468-7716 6711 Forest Park Dr Arlington, TX 76001-8403 Download my résumé in PDF, MS Word, HTML, text http://www.atrixnet.com/ the open source ooOPps Code Library (programs, scripts, code, tutorials) http://ooopps.sourceforge.net/pub/

I've got exactly the same problem. Mozilla 1.1b, Win98SE, using quicklaunch. But I see you are working on it. I hope to get a fixed Mozilla soon, thanks. I allready posted in bug 162290 but eventually I found this bug (since I searched on "preferences" and this bug only has "prefs", I think a lot of diplucates are made, because the summary doesn't have enough keywords?) Bug 162290 isn't a duplicate, I think. But I first thought I had the same problem, so I Commented there first.

It sounds like a few folks are seeing this on branches/trunk besides 1.0.1. We may need to open a new bug (for those branches such as 1.1) or reopen this bug.

Although I would like to continue to help, I don't know how to create an autoexec.bat file, and my operating system is ME, not 98. What I've been doing to get around the problem is sending the drafts as messages to myself. Not very efficient, but all I've got to go with.

*** Bug 163421 has been marked as a duplicate of this bug. ***

*** Bug 163700 has been marked as a duplicate of this bug. ***

Using Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1b) Gecko/20020816 First crash of Mozilla since I've installed that build (I had 1.1a before I think), and my prefs didn't disappear! A crash would almost always create the problem for me, so I'm keeping my fingers crossed! Cheers!

*** Bug 166834 has been marked as a duplicate of this bug. ***

*** Bug 131906 has been marked as a duplicate of this bug. ***

*** Bug 168184 has been marked as a duplicate of this bug. ***

I still see this one on Mozilla 1.1 Sun Sparc. Was this patch checked into that branch ? If yes, this patch does NOT solve the problem, and we have to reopen.

re comment 139 - that cannot be this bug, as Sun does not have the Quicklaunch. if you can't find another bug that relates to your problem, you should open a new one.

*** Bug 169360 has been marked as a duplicate of this bug. ***

*** Bug 158144 has been marked as a duplicate of this bug. ***

*** Bug 122114 has been marked as a duplicate of this bug. ***

very rare, but I just lost my prefs.... quicklaunch was active. 1.2a (20020910). this should be reopened or a spin-off bug should be created.

Waheed, do you have PC-Cillen running? It's a virus checker that has been known to cause this.

Someone asked about PC-Illin from TrendMicro. I use this virus checker on my Windows XP system, where I have seen the problem. I have not seen the problem on my Win98 system with PC-Illin nor on a Windows NT system - which has Norton.

nope, no antivirus software installed. I just lost my profile again! how strange. I believe it might be happening when you convert your profile from a previous version of moz to the new one (first time I did it). And constantly start the mail client before the browser(!) (right-click tray icon - mail). I think the previous version of moz I had was 1.1 (wasn't the patch checked-in?). no definite way of reproduction though. I won't post anymore comments until it happens again using 1.2b and with a fresh profile.

The loss of prefs (mail account) occured on Windows XP Home with mozilla 1.1 final, polish version. It has happened twice in two days (after not happening for a couple of weeks since moz. 1.1 was installed). I think that in both cases mail window was opened before the browser. And of course quick launch was active. I think this bug should definitely be reopened.

Will folks that still experience this problem do the following: do a search for *.vbs and check for any signs of a visual basic virus that might be renaming the prefs.js file that would cause Netscape to lose the mail preferences. this was just in from support folks and it may be related here

I do not use quicklaunch. I do have a single profile (4 mail accounts + 1 newsgroup account). I leave browser and mail running on my WinXP Pro laptop, typically hibernating at the end of the day rather than shutting down. I've had 3 variations of this problem. The first time I just lost mail preferences & re-entered them. The second time the wizard came up telling me I had lost preferences but I shut down Mozilla and re-started and preferences were there. The third time I lost preferences and bookmarks and they wouldn't come back. I had switched to Mail as my preferred first app. For now I am making my own copy of prefs.js

I too do not believe this is associated with QuickLaunch. I am running Mac OS X, and have had it happen to me with 1.2b and the latest nightly builds. As a result, I am still using 1.1, which seems fine (apart from the odd reversion of the bookmarks file to the default, but I can live with that).

this bug _was_ related to quicklaunch and _is_ now fixed. if you've lost profile data when not using quicklaunch on the Windows build, or with a more recent build than 1.1, then you are not seeing this particular bug. there are a bunch of other bugs about profile data problems - take a look at the other depencies of the tracking bug 123929 for possibilities.