284699 - Thunderbird 1.0 crash when started for the first time [@ nsSeamonkeyProfileMigrator::FillProfileDataFromSeamonkeyRegistry]

Status: RESOLVED FIXED

(Thunderbird :: General, defect)

Description

[David Costanzo]

User-Agent:       Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.7.5) Gecko/20041217
Build Identifier: Mozilla/5.0 (Windows; U; Win95; en-US; rv:1.7.5) Gecko/20041217

Thunderbird 1.0 crashed when it was started up for the first time on my machine.
 I think, as the Installer was starting Thunderbird for the first time, I
double-clicked on the shortcut that was put on the desktop.  That may be part of
the problem.

I have never used Thunderbird on this machine, so it's not a problem with
profile migration.  It may be a race-condition between starting two instances at
the same time before the profile directory exists.

My machine is far below the minimum specifications.  It is a Win95 box running
at 90 MHz.  I reporting this because I have a talkback ID and I hope that
associating a bug report will make it easier to track down the bug (if it even
is a bug).

I have not been able to reproduce the problem by starting two instances of
Thunderbird at the same time.  I haven't tried deleting my profile and then
starting two at the same time.

Talkback ID: TB4047748G


Reproducible: Couldn't Reproduce

Comment 1

[timeless]

Incident ID: 4047748
Stack Signature	nsSeamonkeyProfileMigrator::FillProfileDataFromSeamonkeyRegistry
0490bcaa
Product ID	Thunderbird10
Build ID	2004120606
Trigger Time	2005-03-01 17:13:01.0
Platform	Win32
Operating System	Windows 95 4.0 build 67109814
Module	THUNDERBIRD.EXE + (00560aee)
URL visited	
User Comments	Starting up Thunderbird for the first time on a slow (90 Mhz)
Windows 95 machine.
Since Last Crash	0 sec
Total Uptime	0 sec
Trigger Reason	Access violation
Source File, Line No.
e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mail/components/migration/src/nsSeamonkeyProfileMigrator.cpp,
line 366
Stack Trace 	
nsSeamonkeyProfileMigrator::FillProfileDataFromSeamonkeyRegistry 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mail/components/migration/src/nsSeamonkeyProfileMigrator.cpp,
line 366]
nsSeamonkeyProfileMigrator::GetSourceProfiles 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mail/components/migration/src/nsSeamonkeyProfileMigrator.cpp,
line 332]
nsProfileMigrator::GetDefaultMailMigratorKey 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mail/components/migration/src/nsProfileMigrator.cpp,
line 153]
nsProfileMigrator::Migrate 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mail/components/migration/src/nsProfileMigrator.cpp,
line 82]
xre_main 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/toolkit/xre/nsAppRunner.cpp,
line 1820]
main 
[e:/builds/tinderbox/thunderbird-branch/WINNT_5.0_Clobber/mozilla/mail/app/nsMailApp.cpp,
line 58]
KERNEL32.DLL + 0x18f75 (0xbff88f75)
KERNEL32.DLL + 0x18e23 (0xbff88e23)
KERNEL32.DLL + 0x1783f (0xbff8783f)

Comment 2

[David Costanzo]

I have reproduced this several times since I originally filed the bug report
(talkback IDs: TB4097612Y, TB4097519Q, TB4097496W, TB4097460H).

Reproducibilty: Always

Steps to Reproduce:
1) Delete all user-specific Thunderbird data.
   For me, this is a matter of deleting c:\windows\Thunderbird
2) Start Thunderbird

What Happens:
Thunderbird crashes.

Expected Result:
Thunderbird starts up.

Note that Thunderbird creates a profile directory before it crashes and it will
start up fine the next time it is run.

I have also reproduce this problem with Firefox 1.0, but it doesn't have a
talkback agent.  I could not reproduce this with Mozilla.

It looks like the whole starting two-instances-at-the-same-time was a red
herring.  In fact, since this is such an obvious repro scenario, the problem is
more likely to be my unsupported OS or my unsupported (slow) CPU.

Comment 3

[Scott MacGregor]

i see 22 talkback reports with this stack trace and all of them are Win95 users.
Must be something with that old OS and our registry calls that are disagreeing.

Comment 4

[Scott MacGregor]

Attachment: null ptr protection