Closed Bug 105486 Opened 20 years ago Closed 12 years ago

crashes at launch with no sig in migrated 4.x profile


(MailNews Core :: Backend, defect)

Not set


(Not tracked)



(Reporter: m_mozilla, Unassigned)


(Keywords: crash)


(7 files)

From Bugzilla Helper:
User-Agent: Mozilla/4.78 (Macintosh; U; PPC)
BuildID:    Fizilla 0.9.5 (??? 20011015 ???)

mozilla crashes at launch, after splash/loading graphic disapears and after menu 
bar is drawn.

Reproducible: Always
Steps to Reproduce:
launch mozilla
watch initial splash screen / loading progress screen
watch it go away
watch menu bars get drawn
watch mozilla crash

Actual Results:  mozilla crashes

Expected Results:  mozilla does not crash

installed OSX
installed Fizilla
launched Fizilla
(told it to import my NN4 profile, which it seemed to do)
crashed after import progress window went away
re-launched mozilla
crashed again, after mozilla splash/loading screen went away
repeated launch-and-crash several times
turned on crash logs and rebooted machine
relaunched/crashed mozilla

console says:

2001-10-18 14:50:00.597 SystemUIServer[300] Got nil as the string argument in 
NSMutableString. Pass empty string instead. Will probably crash.
Oct 18 14:50:00 image1 /usr/libexec/CrashReporter: Succeeded writing crash 
report: /Users/wickline/Library/Logs/Mozilla.crash.log

Oct 18 14:50:02 image1 /usr/libexec/CrashReporter: Succeeded writing crash 
report: /Users/wickline/Library/Logs/SystemUIServer.crash.log

will attach logs shortly...

this is OSX 10.1
I've seen this also, and believe it's related to Mac Mozilla unexpectedly
quitting because an error of type 2 occurred as I reported in bug 105470.
Severity: blocker → critical
Keywords: crash and Greg: the bug Greg mentions is fixed. Are you still
seeing this?

Gerv, FYI, the bug I mentioned was marked a duplicate of bug 102931, which is not fixed.

Since a crash report is attached hereon, it should be easy to verify that the crash is the same.
I get exactly the same problem under 8.6 since around 5 nighly builds...
I have not been downloading the nightlies due to the Mac blocker bug 10622, so I
tried last nights (Build from November 12, 2001) build to see if this bug was
fixed. The build quit after the splash screen. I am using Mac OS 8.6 on a 350mhz
B&W G-3. I have not been able to use any nightly after 0.95 due to blcker bugs.
Sould this bug be listed for all Mac platforms or is the bug I am experiencing
on Mac classic a different bug than that for OS X?
I meant to say Mac blocker bug 106022. :(
Sorry not since 5 but 2 nightly builds...  2001100904 works great. I will open a 
new bug.
I downloaded the latest build (2001-11-13), and now I am seeing
the same crash.  2001-11-01 build works fine, as well as 2001101516.
Nothing Mozilla related on console (using Mac OS X Version 10.1.1 (5M28)).
Using terminal and typing "open /Applications/Mozilla/"
gave the same result, splash screen showing and then crash.  No output
on terminal.

On the other hand, if I am running an older version of Mozilla,
the new version *is* able to detect this, puts up an error message
and quits cleanly.  

I couldn't find a crash log -- but I don't know where to look for.
this bug originally happened for me on a 350MHz blue and white g3, but didn't happen on my primary machine (500MHz grey g4 AGP graphics). Both of those machines are now running Mac OS X 10.1.1 and I've just installed Fizilla 0.9.6 on each. The g4 still runs fine. The g3 still crashes at launch, after menu bars get drawn but before a browser window materializes.

I'll attach the latest mozilla and ssytemUIserver crash logs.

mozilla crash log with 0.9.6
system ui server crash log from same crash with 0.9.6
Asa, can you analyze the crash report attached by mmozilla?
I don't know how to read anything in these crash logs. smfr or pink, can one of
you take a look at this? thanks.
Can you try a nightly build instead of a milestone build? The latter are built 
with symbols turned off, so the logs are not useful.
at about 7:20am pacific time (give or take a few minutes) I downloaded 

This build also crashed on the blue and white g3. I'll attach both logs from the crash.

hopefully they'll be more informative :)

oh... and the download time of the nightly build was actually about 6:20am
pacific... within 15min of this comment posting. Darn time zones :)
and here's the system ui crash log as well.

Does anyone who's authorized want to obsolete the crash logs w/o any useful
I'm curious.

Are the folks who have seen this bug all seeing it on blue and white G3 macs?

Has anyone seen it on any other mac?

I've seen it consistently on my blue and white g3,
and never seen it on the following other machines:
    g4 powerbook
    g4 minitower, AGP
    g3 lime imac

out of curiosity, I tried

it also crashed. Not attaching crash logs, as per sfraser's earlier comment that they are not so usefull with release builds

I didn't see an OSX build in the 0.9.3 directory.

i bet you have a UFS volume, no? that would be my best guess.
Whiteboard: DUPEME
The blue and white G3 with the mozilla crashes has zero UFS volumes.
It has two HFS volumes and one HFS+ volume.
The OS and the mozilla app are both on the HFS+ volume.

The other machines have all HFS+ volumes.

This is odd. The mozilla stack is:

Thread 0:
 #0   0x005c0b28 in _as__10nsFileSpecFPCc
 #1   0x005c0b1c in _as__10nsFileSpecFPCc

and the crash is on this thread, as far as I can tell.
Whiteboard: DUPEME
Are there any interesting chars in your paths (and are they long/deep) to 
mozilla or other things?
The stack in attachment 59314 [details] is so shallow - I wonder what really happened. It
probably crashed, wiped out the stack, and what was left happened to be in
no funky characters in the path to mozilla.

That should be the standard path under MacOS X.

Regarding funky paths to "anything else", there shouldn't be any, but if you have some specifics for me I can look into them. This OSX install is pretty basic. There's no developer tools. The only possibly unusual thing I can think of is that this machine has DAVE installed so it can play nice on PC networks.

If I get a chance this morning, I'll uninstall DAVE and see if that has any affect.

unistalled DAVE.
mozilla crash logs look the same to me... and it did still crash

I can't think of anything else unusual about this settup.

can you run a truss/strace equivalent? it'd be at least interesting to know 
what the last files to be opened were... (yes, i've been grasping at straws for 
a while now, but hey they might be out there).
% which truss
truss: Command not found.
% which strace
strace: Command not found.
% apropos trace
traceroute(8)            - print the route packets take to network host
trpt(8)                  - transliterate protocol trace
trsp(8)                  - transliterate sequenced packet protocol trace


nothing via google or versiontracker either

downloading/installing OX 10.1 developer tools...

no joy. :(

Anyone know of a suitable tool I could download?

Well, I couldn't find a truss or strace after installing the devtools,
but I did find MallocDebug.

Of course, I have no real idea of how to use it.
I attached it to and launched it from within there.

Unfortunately, when moz crashed, a dialog box pops up saying_
  Target_application_crashed_  /Applications/Mozilla/  accessed memory at 0x41414194 illegally.                                             {[   OK   ]}
and when you click OK, all the gathered data vanishes.

If I switch to another app, I can record the visible info
in three columns of recorded data. By viewing different
portions of of the data at the time of the crash, and then
switching apps when the crash comes, I can manually type
various portions of the visible data. Note that since the
portions will be visible at different points of execution,
the numbers may not add up properly. Also, typos may be

This was a real PITA, but if you find it useful, I'm willing
to try to follow specific other portions of the allocation
tree. I stopped when It looked like I was getting into an
endless list of Core Foundation and Core Graphics Service

The bits at the end, re: "dwarf" this and that look most
unusual. Do they give any clues?

This was with the 0.9.6 OSX release. If a nightly would be
more helpfull for this, I can do that. If anyone has any
clues on how to better use MallocDebug, I'd appreciate them.
If anyone has any clues on which portions of the tree would
be worth closer investigation, that would be good too.

FWIW, the console gave the following for each crash:
MallocDebug: Target application attempted to read address 0x41414194, which can't be read.MallocDebug: MallocDebug can't do anything about this, so the app's just going to have to be terminated.MallocDebug: *************************************************MallocDebug: THIS IS A BUG IN THE PROGRAM BEING RUN UNDER MALLOC DEBUG,MallocDebug: NOT A BUG IN MALLOC DEBUG!MallocDebug: *************************************************


41.6K start    41.6K _start        40.5K _call_mod_init_funcs            40.5K _dyld_make_delayed_module_initializer_calls                78.1K call_image_init_routines                    40.5K call_dependent_init_routines                        40.5K call_dependent_init_routines                            40.5K call_dependent_init_routines                                40.3K call_dependent_init_routines                                    40.3K __CFInitialize                                        32.9K __CFStringInitialize                                            32.9K __CFStringMakeConstantSTring                                                32.8K _CFDictionarySetCapacity                                                    ... I didn't look in here ...                                                76K CFDictionaryCreateMutable                                                    ... I didn't look in here ...                                                40K CFStringCreateWithCString                                                    ... I didn't look in here ...                                            3.8K __CFRuntimeInitialize                                                    ... I didn't look in here ...                                            1.1K __CFBundleInitialize                                                    ... I didn't look in here ...                                            696K __CFCharacterSetInitialize                                                    ... I didn't look in here ...                                            484K __CFUserNotificationInitialize                                                    ... I didn't look in here ...                                            260K __CFURLAccessInitialize                                                    ... I didn't look in here ...                                            220K __CFPreferencesDomainInitialize                                                    ... I didn't look in here ...                                            188K __CFStreamInitialize                                                    ... I didn't look in here ...                                            168K __CFPlugInInitialize                                                    ... I didn't look in here ...                                            160K __CFSocketInitialize                                                    ... I didn't look in here ...                                            116K __UtilitiesInitialize                                                    ... I didn't look in here ...                                            72K __CFPasteboardInitialize                                                    ... I didn't look in here ...                                            64K __CFRunLoopInitialize                                                    ... I didn't look in here ...                                            48K __CFNumberInitialize                                                    ... I didn't look in here ...                                            40K __CFRuntimeInitialize2                                                    ... I didn't look in here ...                                            ... a few others at this level did not fit in viewable part of list...                                236 _InitCarbonCore                                    ... I didn't look in here ...                    37.6K _initHLTB                        19.4K INIT_Processes                            19.4K RegisterProcess                                18.4K _CGSDefaultConnection                                    17.9K CGSInitialize                                        9.0K _CGSDisplayInitialize                                            ... I didn't look in here ...                                        5.4K _CGSConnectionInitialize                                            ... I didn't look in here ...                                        2.4K _CGSPackageInitialize                                            ... I didn't look in here ...                                        679 CGSInitializeOperating Flags                                            ... I didn't look in here ...                                        196 _CGSWindowInitialize                                            ... I didn't look in here ...                                        132 _CGSShmemInitialize                                            ... I didn't look in here ...                                        (some of the following entries obscured by crash dialog)                                        xxxxxxxxitialize                                            ... I didn't look in here ...                                        xxxxxxxxventInitialize                                            ... I didn't look in here ...                                        xxxxxxxxitialize                                            ... I didn't look in here ...                                    480K CGSNewConnection                                        ... I didn't look in here ...                                13.3K CPSRegisterWithServer                                    ... I didn't look in here ...                            2.6K INIT_HLTBLowMem                                ... I didn't look in here ...        1.1K __keymgr_dwarf2_register_sections        1.1k _dyld_register_func_for_add_image            1.1K register_func_for_add_image                1.1K dwarf2_unwind_dyld_add_image_hook                    936 calloc                    124 _keymgr_get_and_lock_processwide_ptr                        72 _keymgr_get_and_lock_key                            72 _keymgr_get_or_create_key_element                                72 _keymgr-create_key_element                                    72 malloc                        52 _init_keymgr                            52 malloc

uh... that didn't work very well.
How about an attachment instead?
I tried to download the pdf, but was denied.
Maybe I need to have an appropriate referer header with my request?
On what page did you find that link?

I found HTML documentation on apple's site, and read that.
Unfortunately, I think I need more hand-holding.

    % cd /Applications/Mozilla

now if I just do

    % sudo fs_usage -w Mozilla > fs_usage.txt

then I get an fs_usage.txt file containing

    fs_usage: the trace facility is currently in use...              fs_usage, sc_usage, and latency use this feature.

and nothing else. I was hoping that fs_usage would keep running
and I could then fire up Mozilla, wait for it to crash, and then
stop the fs_usage process.

So, maybe I need to have Mozilla running when I call fs_usage.

    % open; sudo fs_usage -w Mozilla > fs_usage.txt

nope... same output. Maybe I need to be more specific...

    % open; sudo fs_usage -w > fs_usage.txt

nope... same output. Maybe I need to back up a bit...

    % open; sudo fs_usage -w open > fs_usage.txt
nope... same output.

What should I be doing?

FYI: I tried forging a referer header of
to access that PDF, but was still disallowed.

From the very first comment on this bug:
    SystemUIServer[300] Got nil as the string argument in NSMutableString.
    Pass empty string instead.
    Will probably crash.

This message (or one with a different PID in the brackets... I think that's a PID) appears in the cosole for every one of these crashes. Is this any more informative than the crash logs?

What is NSMutableString? What calls it?
NSMutableString (Objective-C)
PATH Documentation > Cocoa > Foundation API Reference: Objective-C.
Table of Contents NSMutableString. ... 
ObjC_classic/Classes/NSMutableString.html - 16k - Cached - Similar pages

My guess is that some string like that is being sent to something like

but i'm _not_ a Cocoa developer and I tried reading the mozilla mac file code 
and couldn't find anything risky (well something puzzled me but then i woke up 
a bit and saw the line i missed).

fs_usage sounds like what i was trying for

fwiw if someone suggests something and you can't find it, please try google, it 
works wonders might be an even better starting 
thanks for the info, but that was the documentation I had
already found on apple's site. (I'm also a huge google fan.)

I need more direct instruction than that. See my failed
attempts in my previous comment. I used fs_usage the way I
thought the documentation said I should and got no useful

Can you point out what I did wrong?

Can you provide more specific instructions?

It's probably not going to help, but can you try creating a new profile (one
that's not migrated from 4.x) and see if your results are any different. You can
do this by dragging the "Mozilla Profile Manager" icon onto the Mozilla app. If
it makes it as far as launching the profile manager then hit "create profile"
and make a new profile. 
...and now my coworkers are wondering what's so joyous
in my cubicle to warrant a loud cheer! :)

That *did* it! Yippie!!!     Thank you! :)

So, what's the next step?

I've got one profile that consistently crashes at launch,
and another that consistently works just dandy. I'm thinking
that I should start swaping files until either the good one
goes bad or the bad one goes good.

Do the profile documents get read in any specific order, or
are multiple documents being read by multiple threads? I'm
wondering if I can do this faster with a bit of binary
process of elimination... is the bad file in the first half,
or the second half of the files... etc.

Once I find the bad file, I'll see if I can isolate which
part of the file, or maybe just post the whole thing as
an attachment to this bug if I can't manage that.

So, any clues as to file load order, or should I just do
it one file at a time?

finding the problem file would be great. The suspect files that I'd try first
are localstore.rdf, prefs.js, bookmarks.html and history.dat. You can simply
rename the file and a new one should be created on startup. when your startup
succeeds you'l know which one was to blame. Those are all readable in a text
editor so if you isolate one of them as the culprit you can compare it's
contents to that of a working file to see if there is anything suspicious. 

You could also try to migrate your 4.x profile again and see if it's something
specific to the 4.x profile contents or the migration process (you could even
create a couple of additional 4.x profiles and migrate them to determine if it
was the profile contents or the migration that was the problem). 

Let me know what you find. I'm glad that this solved your problem. (it's usually
the first thing I ask people to test and I'm sorry you did so much before I
thought to suggest that. thanks for your persistance.)
This line of prefs.js is to blame:
(no whitespace in original value, just added for legibility)

    user_pref("mail.signature_file", "AAAAAAGkAAIAAAVtYWNvcw

I don't use a signature file. So, maybe the profile conversion
process takes "no file spec" and turns it into the above,
which some other code then assumes decodes to a string and
accidentally hands an undefined value where one is not
allowed, leading to the message in the console:
    Got nil as the string argument in NSMutableString.
    Pass empty string instead. Will probably crash.

Opening NN4.79 in Classic confirms that I have no path
specified for a sig file, and don't have that box checked.

The exact same line is found in my Netscape Preferences
file from the 4.79 prefs folder. I don't really have any
way of telling whether that mystery string encodes a
path to some ancient prefs file (which I'm sure is no
longer a valid path as I haven't used a sig in years),
or whether it encodes "no file at all".

I guess this one is back in your court :)

now we know --> profile migration
Assignee: asa → racham
Component: Browser-General → Profile Migration
QA Contact: doronr → ktrina
Summary: crashes at launch → crashes at launch with no sig in migrated 4.x profile
Delete the signature_file prefs.js line.
launch mozilla.
look at settings for that mail account.

"Attach this signature" is *checked*
and the field below (path to sig) is blank.

"Attach this signature" should not be checked.

"Attach this signature" is also checked in the news settings,
again with the blank path below.

Maybe the migration is checking to see if something is in
and if so, it checks these boxes. Then some other bit of
code is more clever and looks to see if the path is valid
before filling it in. If so, then the code that checks the
boxes needs to be similarly clever.

Isn't this a mail bug?
Ever confirmed: true
mass re-assign.
Assignee: racham → sspitzer
3 years later...

Moz no longer imports from Netscape 4. Should this bug be closed?
sorry for the spam.  making bugzilla reflect reality as I'm not working on these bugs.  filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Filter on "Nobody_NScomTLD_20080620"
QA Contact: ktrina → profile-migration
This is no longer valid as a profile-migration bug (comment 48), but before closing this bug, we should make sure that a bogus nsILocalFile::persistentDescriptor in the mail.signature_file pref (comment 42) no longer crashes or causes other issues.

FWIW, comment 42 encodes something along the lines of "macos:Notes and MIME:~simple case for mgr meeting:msg_01:sig.txt
Component: Profile: Migration → Backend
Product: Core → MailNews Core
QA Contact: profile-migration → backend
To test:

1. Close Thunderbird.
2. Add the line from comment 42 to prefs.js (remove whitespace) (replacing your mail.signature_file, if any).
3. Open Thunderbird.
4. Send mail to yourself.

If steps 3 and 4 work correctly, this is WFM.  I think bwinton is going to test.
(In reply to comment #52)
> To test:
> If steps 3 and 4 work correctly, this is WFM.  I think bwinton is going to
> test.

So, I tested this using the steps above, but it always seemed to work for me.
I even tried changing mail.identity.id1.sig_file to the bad value, but nothing seemed to fail.

Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.