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.

m_mozilla@wickline.org and Greg: the bug Greg mentions is fixed. Are you still seeing this? Gerv

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/Mozilla.app" 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. -matt

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 http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-macosX-trunk.smi.bin This build also crashed on the blue and white g3. I'll attach both logs from the crash. hopefully they'll be more informative :) -matt

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 data?

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 -matt

out of curiosity, I tried /pub/mozilla/releases/mozilla0.9.4/mozilla-macosX-0.9.4.sit.bin 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. -matt

i bet you have a UFS volume, no? that would be my best guess.

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. -matt

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.

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 nsFileSpec.

no funky characters in the path to mozilla. /Applications/Mozilla/Mozilla.app 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. http://www.thursby.com/products/dave.html If I get a chance this morning, I'll uninstall DAVE and see if that has any affect. -matt

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. :/ -matt

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 hmmm nothing via google or versiontracker either downloading/installing OX 10.1 developer tools... no joy. :( Anyone know of a suitable tool I could download? -matt

Well, I couldn't find a truss or strace after installing the devtools, but I did find MallocDebug. http://developer.apple.com/techpubs/macosx/Essentials/Performance/PerformanceTools/Debugging_A_MallocDebug.html Of course, I have no real idea of how to use it. I attached it to Mozilla.app and launched it from within there. Unfortunately, when moz crashed, a dialog box pops up saying_ Target_application_crashed_ /Applications/Mozilla/Mozilla.app/Contents/MacOS/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 introduced. 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 stuff. 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: ************************************************* -matt 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? sorry, -matt

Try fs_usage also. Details are in http://developer.apple.com/techpubs/macosx/Essentials/Performance/Performance.pdf

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 Mozilla.app; sudo fs_usage -w Mozilla > fs_usage.txt nope... same output. Maybe I need to be more specific... % open Mozilla.app; sudo fs_usage -w Mozilla.app > fs_usage.txt nope... same output. Maybe I need to back up a bit... % open Mozilla.app; sudo fs_usage -w open > fs_usage.txt nope... same output. What should I be doing? -matt

FYI: I tried forging a referer header of http://developer.apple.com/techpubs/macosx/Essentials/Performance/ to access that PDF, but was still disallowed. -matt

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. ... developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/ ObjC_classic/Classes/NSMutableString.html - 16k - Cached - Similar pages My guess is that some string like that is being sent to something like http://developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/ObjC_clas sic/Classes/NSFileHandle.html 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 http://www.google.com/search?q=cache:L70JbQPGt0Q:developer.apple.com/techpubs/m acosx/Essentials/Performance/PerformanceTools/fs_usage_Fi_alysis_Tool.html+fs_u sage&hl=en fwiw if someone suggests something and you can't find it, please try google, it works wonders http://www.google.com/mac.html might be an even better starting point...

timeless: thanks for the info, but that was the documentation I had already found on apple's site. (I'm also a huge google fan.) http://developer.apple.com/techpubs/macosx/Essentials/Performance/PerformanceTools/fs_usage_Fi_alysis_Tool.html 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 output. Can you point out what I did wrong? Can you provide more specific instructions? -matt

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? -matt

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 AAAAAAAAAAAAAAAAAAAAAAAAAAAACzjmSNQkQAAAAEPb wHc2lnLnR4dAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA Q+zrXT9gdURVhUUipjaP////8AAAARAAAAAAAAAAAAAA AAA AAABm1zZ18wMQABAAwABD28AARI+wAEPbQAAgBAb WFjb3M6Tm90ZXMgYW5kIE1JTUU6fnNpbXBsZSBjYXNlI GZvciBtZ3IgbWVldGluZzptc2dfMDE6c2lnLnR4dAAJA KgAqGFmcG0AAAAAAAMAGAA5AFkAdQCVAJ4WSW50ZXJuY WwgTWVkaWNpbmUgSU1CTwAAAAAAAAAAAAARUENGMDAtd 2lja2xpbmUtRzMAAAAAAAAAAAAAAAAAAAVtYWNvcwAAA AAAAAAAAAAAAAAAAAAAAAAAAAAId2lja2xpbmUAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAD//wAA"); 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 :) -matt

now we know --> profile migration

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. -matt

"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 mail.signature_file 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. -matt

Isn't this a mail bug?

mass re-assign.

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.

Filter on "Nobody_NScomTLD_20080620"

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

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: [snip] > 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. Later, Blake.