Closed Bug 237290 Opened 20 years ago Closed 20 years ago

crash when configuring new account on fresh Mac

Categories

(SeaMonkey :: MailNews: Account Configuration, defect)

Product:
SeaMonkey
Component:
MailNews: Account Configuration
Version:
1.0 Branch
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
blocker

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: Brade, Assigned: jshin1987)

References

Details

(Keywords: crash)

Attachments

(2 files)

crash log
39.54 KB, text/plain
Details
patch
1006 bytes, patch
Bienvenu
: superreview+
chofmann
: approval1.7+
Details | Diff | Splinter Review 
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? 

10.2.*
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.
Attached file crash log — 
The mozilla 1.7b release version is also reproduced.
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.
Attached patch patch — — Splinter Review 
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.
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
Closed: 20 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. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.