I downloaded Thunderbird last month, entered the basic settings to get started and it crashed. I tried a newer build (today) and I see the same behavior. Here is a partial stack from crashreporter: #0 0x90000e60 in strlen #1 0x0a001df4 in nsFileSpec::GetLeafName() const #2 0x0195aabc in NSGetModule #3 0x0195a9d0 in NSGetModule #4 0x0194e060 in NSGetModule #5 0x0194c8ec in NSGetModule #6 0x01954b38 in NSGetModule #7 0x01954910 in NSGetModule #8 0x019eb730 in NSGetModule #9 0x01989ee8 in NSGetModule #10 0x019877a8 in NSGetModule #11 0x01985984 in NSGetModule #12 0x006c091c in NSGetModule #13 0x023078b0 in NSGetModule #14 0x0230c79c in NSGetModule #15 0x0230c8c0 in NSGetModule #16 0x0230c8c0 in NSGetModule #17 0x0231de98 in NSGetModule #18 0x0231e2f8 in NSGetModule #19 0x006c1c50 in NSGetModule #20 0x01983b10 in NSGetModule #21 0x0500f414 in nsSupportsArray::EnumerateForwards(int (*)(nsISupports*, voi d*), void*) Note: I did "cancel" the setup and did not crash. Note: whether I download my pop3 mail or not (checkbox on last screen) is not relevant (I still crash).
I wonder if the fix for bug 227547 caused this - cc'ing jshin. Kathy first tried this about a month ago, and it was crashing then too. She tried the Feb 08th build just now, but it doesn't seem to launch.
Adding Conrad to Cc. brade, what's your OS version?
A few updates which I forgot to add to the bug: * if I cancel the initial profile configuration, I don't crash and can Quit normally * if I configure an IMAP account, I don't crash * if I configure a news account, I don't crash * checking/unchecking the "don't download now" for a pop account has no affect I don't have a thunderbird tree so I can't really debug except with downloadable builds.
The place which has crashed looks the same although I am using 10.3.3. In account creation of pop3, when the finish button was finally pushed, it generated.
Thanks for the crash log. So, it's also happening on 10.3 as well. brade, does it also happen with Mozilla-mail? It must happen with Mozilla-mail, too. If it does and you have a mozilla tree, can you build a debug build and see what's going on in nsFileSpec::GetLeafName()? I can't see what can go wrong there with my change. Conrad, do you have any idea? Alternatively, crot0, do you have a build environment and build a debug build? I don't have a Mac (I have a remote access to a Mac and made a patch that way for bug 227547, but that doesn't help in this case because I can't run Mozilla/TB remotely)
(In reply to comment #7) > Alternatively, crot0, do you have a build environment and build a debug build? Sorry... Although it already has the build environment, debug build is created and the machine resource to debug is lacking.
Created attachment 144383 [details] [diff] [review] patch Sorry I was looking at the wrong file (nsFileSpecMac.cpp) which still happens to include my obsolete patch. It seems like GetLeaf('/') returns null at http://lxr.mozilla.org/seamonkey/source/xpcom/obsolete/nsFileSpecUnix.cpp#146 In this patch, I made GetLeafName return immediately in that case.
Assignee: mscott → jshin
Status: NEW → ASSIGNED
crot0 and brade, can you apply the patch and see if it prevents the crash?
(In reply to comment #9) > Created an attachment (id=144383) > patch When this patch was applied, the crashing problem fixed!! Please checkin :-)
Comment on attachment 144383 [details] [diff] [review] patch looks good.
Attachment #144383 - Flags: superreview?(bienvenu)
Attachment #144383 - Flags: superreview?(bienvenu) → superreview+
Comment on attachment 144383 [details] [diff] [review] patch thanks for sr, David. asking for r.
Attachment #144383 - Flags: review?(ccarlen)
Comment on attachment 144383 [details] [diff] [review] patch r=ccarlen
Attachment #144383 - Flags: review?(ccarlen) → review+
changing product - I suspect this affects seamonkey too.
Component: Account Manager → Account Manager
Product: Thunderbird → MailNews
Version: unspecified → 1.0 Branch
Comment on attachment 144383 [details] [diff] [review] patch requesting 1.7 approval
Attachment #144383 - Flags: approval1.7?
Comment on attachment 144383 [details] [diff] [review] patch a=chofmann for 1.7
Attachment #144383 - Flags: approval1.7? → approval1.7+
thanks for r/sr and a. fix checked into the trunk with nameInNFC declaration moved closer where it's used.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
for reference: neither your r= nor your sr= are valid for xpcom.
For your information, timeless, xpcom/obsolete is not part of xpcom proper. It's not part of xpcom.dll.
*** Bug 239834 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.