Closed
Bug 22001
Opened 25 years ago
Closed 25 years ago
[DOGFOOD][PP]Crashed when trying to read the send message from the messages thread pane
Categories
(MailNews Core :: Composition, defect, P3)
MailNews Core
Composition
Tracking
(Not tracked)
VERIFIED
FIXED
M13
People
(Reporter: huang, Assigned: bugzilla)
References
Details
(Whiteboard: [PDT+] Verified on all platforms)
Attachments
(1 file)
(deleted),
patch
|
Details | Diff | Splinter Review |
Crashed when trying to read the send message from the thread pane:
1) Select the new msg to send message.
2) tried to read the message from the message thread pane to verifying for
receiving messages.
3) Actual Results: Crashed.
Expected results: Should load the messages header successfully and read the
message from the message body.
This only happened for the first time read message after send.
After crashed and bring up the mail again, can read from the second time.
Talkback# are available but for some reason, cannot see today's talkback report
yet.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Target Milestone: M13
Reporter | ||
Comment 1•25 years ago
|
||
See Talkback#2599502, 2599603, 2600616
Following is the talkback#2599502
libaddrbook.so + 0x24e69 (0x411f5e69)
nsCAimABInfo::GetScreenNameFromEmail()
[/builds/client/linux22/mozilla/ns/AIMGlue/src/nsCAimABInfo.cpp, line 257]
nsMimeMiscStatus::GetIndividualXUL()
[/builds/client/linux22/mozilla/ns/mailnews/mime/aimstatus/src/nsMimeAIMStatus.cpp,
line 140]
libmimeemitter.so + 0x723d (0x411ba23d)
libmimeemitter.so + 0x6eec (0x411b9eec)
libmimeemitter.so + 0x6a62 (0x411b9a62)
libmimeemitter.so + 0x686d (0x411b986d)
libmimeemitter.so + 0x633e (0x411b933e)
libmimeemitter.so + 0x63d3 (0x411b93d3)
libmimeemitter.so + 0x5d6d (0x411b8d6d)
libmime.so + 0x1eeee (0x41106eee)
liburiloader.so + 0x23fe (0x409203fe)
libraptorwebwidget.so + 0xf216 (0x40898216)
libnecko.so + 0xae30 (0x4049be30)
libnecko.so + 0xa8c0 (0x4049b8c0)
libplds3.so + 0x1c17 (0x40113c17)
libplds3.so + 0x1b86 (0x40113b86)
libxpcom.so + 0x6031a (0x400f231a)
libwidget_gtk.so + 0x221e7 (0x405051e7)
libwidget_gtk.so + 0x21dad (0x40504dad)
libglib-1.2.so.0 + 0xe3ca (0x406993ca)
libglib-1.2.so.0 + 0xfa86 (0x4069aa86)
libglib-1.2.so.0 + 0x10041 (0x4069b041)
libglib-1.2.so.0 + 0x101e1 (0x4069b1e1)
libgtk-1.2.so.0 + 0x8b7a9 (0x405c47a9)
libwidget_gtk.so + 0x22635 (0x40505635)
libnsappshell.so + 0x11532 (0x4045b532)
mozilla-bin + 0x25d5 (0x0804a5d5)
mozilla-bin + 0x2859 (0x0804a859)
libc.so.6 + 0x17cb3 (0x401f8cb3)
cc: amusil. Stack trace shows AIM.
Karen, I assume this is occurring for various messages and not just one
particular message?
Comment 3•25 years ago
|
||
Syd - can you repro this on your Linux box?
Reporter | ||
Comment 4•25 years ago
|
||
Yes. I think so.
I can reproduce for three times after I send the message and trying to read the
message header from the thread pane.
But it's not crashing every time...but I can reproduce that if I tried many
times.
Reporter | ||
Comment 5•25 years ago
|
||
Crashed on WinNT for same scenario.
Talkback#2601702 for WinNT
nsAddrDatabase::GetCardForEmailAddress
[d:\builds\seamonkey\mozilla\mailnews\addrbook\src\nsAddrDatabase.cpp, line
2683]
IMGlue.dll + 0xe305 (0x0a5fe305)
aimstat.dll + 0x1959 (0x0ad61959)
nsMimeXULEmitter::ProcessSingleEmailEntry
[d:\builds\seamonkey\mozilla\mailnews\mime\emitters\src\nsMimeXULEmitter.cpp,
line 994]
nsMimeXULEmitter::OutputEmailAddresses
[d:\builds\seamonkey\mozilla\mailnews\mime\emitters\src\nsMimeXULEmitter.cpp,
line 906]
nsMimeXULEmitter::WriteEmailAddrXULTag
[d:\builds\seamonkey\mozilla\mailnews\mime\emitters\src\nsMimeXULEmitter.cpp,
line 751]
nsMimeXULEmitter::WriteXULTag
[d:\builds\seamonkey\mozilla\mailnews\mime\emitters\src\nsMimeXULEmitter.cpp,
line 678]
nsMimeXULEmitter::OutputGenericHeader
[d:\builds\seamonkey\mozilla\mailnews\mime\emitters\src\nsMimeXULEmitter.cpp,
line 539]
nsMimeXULEmitter::DumpSubjectFromDate
[d:\builds\seamonkey\mozilla\mailnews\mime\emitters\src\nsMimeXULEmitter.cpp,
line 558]
nsMimeXULEmitter::Complete
[d:\builds\seamonkey\mozilla\mailnews\mime\emitters\src\nsMimeXULEmitter.cpp,
line 333]
nsStreamConverter::OnStopRequest
[d:\builds\seamonkey\mozilla\mailnews\mime\src\nsStreamConverter.cpp, line 733]
0x0b2a5e10
I can also reproduce this when I try to select messages at different times. Are
we trying to add something to the address book at the time of the crash?
Comment 8•25 years ago
|
||
I'm building right now and will try to repro this shortly.
alex, also see http://bugzilla.mozilla.org/show_bug.cgi?id=22013 which is dup of
this for more concise steps.
Comment 10•25 years ago
|
||
I'm having trouble reproducing this. What is the setup of AIM and the address
book on your system, Huang?
Comment 11•25 years ago
|
||
huang - let me know when you're free for me to come by and check out the crash on
your machine.
Comment 12•25 years ago
|
||
*** Bug 22013 has been marked as a duplicate of this bug. ***
Comment 13•25 years ago
|
||
alex, I've also seen this on my system. I have nothing in my personal address
book; there are items in the collected address book. At the time of the crash I
received, I am not logged into AIM at all so no buddy list was present.
You can also see if Kat is around at this time (he's usually around late) and he
can show you this bug. (I'm at home now).
huang will be in around 8am Friday.
Thanks
Comment 14•25 years ago
|
||
I'm not at work now but let me add some facts about this problem.
First, I can reproduce this problem just about 100% of the time
following the precise steps I described in Bug 22013.
Second, I thought that there was a bug about Mozilla not
adding the sender's address to the "Collected Address Book"
automatically as msgs are viewed. So I experimented by removing
my sending address from the Collected Address Book folder first
and then tried out the steps mentioned in the other bug. But this
did not change the result. It still crashed the same way. Also
the sender address did not get added. (Later on I viewed this new
msg but that still did not add the sender's address.) There must
be another bug filed for this latter problem. But this is just an
additional observation on that and my experiment.
Comment 15•25 years ago
|
||
I can't reproduce it on my NT using my debug build or release build. The
talkback report on Linux and NT doesn't look like the same problem, the Linux
one is related to AIM, NT's crash is related to collected address book. On my
machine , the collected address book doesn't show up and maybe that's why I
didn't get a crash. Is there a bug about the collected address book doesn't
show up in the address book for new user profile? I'll try to work around to
get the collected address book to show up on my machine tomorrow in order to
reproduce the problem.
Karan or Momoi, please try on a new user profile to see if you can reproduce the
crash.
Alex, if you found anything leads to address book from the AIM side, please let
me know.
Thanks.
Updated•25 years ago
|
Severity: major → blocker
Comment 16•25 years ago
|
||
Thanks, I tried starting with a new profile and found something
very interesting. This looks more and more like a problem
related to the "Collected Address Book Folder". Here's what I found
with 12/16/99 Win32 build.
1. I created a new profile, started Browser, opened Mail, and set
up my mail server account via the account setup menu.
2. ** Without re-starting **, I then opened the Inbox and viewed 2
msgs. Neither came from my test account and so the sender's
names were different.
3. Checking in the Address Book, I found that the Collected Address has
not been created yet.
4. So now I quit Mozilla and started it up again.
5. I looked in the Address Book and found that the Collected
Address Book is now there with the 2 names in it which came
from viewing 2 msgs in step 2. (A known bug to be sure.)
6. Now I followed the steps mentioned in Bug 22013 **precisely** and
received the msg from myself and viewed the msg. There was no crash.
7. I looked in the Collected Address Book and found that this time
the 3rd name was added, i.e. my test account address.
8. Now I followed the steps in Bug 22013 carefully again and received
the msg from myself (test account) and this time it crashed!
Thus, it seems that the existence of your own address in the Collected
Address Book seems to be a trigger for this.
By the way, I looked at my Talkback reports dated 12/16/99 on the Talkback
server under "momoi@netscape.com" and except for 2 crashes which
were caused by different operations on Linux (i.e. 2609614, 2610671),
other 7 rerports dated 12/16/99 show the same dumps involving
"nsAddrDatabase::GetCardForEmailAddress...".
By the way why are we not fixing in M12?
This is going to affect a lot of users. I've changed the status to
blocker again.
Comment 17•25 years ago
|
||
I appeal again to everyone concerned. This should be fixed
for M12.
This is not a random crash. It occurs 100% of the time when
the scenario I described is followed. And the scenario is a
fairly common one which will affect a lot of users.
Comment 18•25 years ago
|
||
Added msanz@netscape.com and bobj@netscape.com. This affects
mail reading negatively far too often and a workaround
"accpeting the crash and re-starting" or some steps too
hard for average people to discover.
Comment 19•25 years ago
|
||
In my earlier comments, I said:
"So I experimented by removing my sending address from the
Collected Address Book folder first and then tried out the
steps mentioned in the other bug. But this did not change
the result."
I want to correct this statement. Apparently I had used several
different names for the same test account e-mail address and
I did not remove all instances of the same address
from the Collected Address Book Folder and was not able to
avoid the crash.
Also another observation on reproducing this bug. On a new
profile, if the crash does not occur at step 8 above,
then it helps if you quit and go through the steps
again. Once or twice I was not able to get the crash
at first but when I re-started once or twice, I was
able to get the crash going all the time.
Comment 20•25 years ago
|
||
Another debugging tip is that if the crash does not happen
during a new Mozilla session as you view a new
message, it normally does not occur during that session
and you need to re-start Mail again to induce the problem.
Comment 21•25 years ago
|
||
What I meant is that you need to quit Mozilla and
re-start Mozilla/Mail.
Comment 22•25 years ago
|
||
I got my collected address book. I can't get a crash using 12-16's release
build using momoi's steps, I quit and restart mozilla several times. I have
only one mail account. It didin't add my email address repeatedly in the
collected address book. I'll try starting a brand new profile.
Comment 23•25 years ago
|
||
I started a new profile, follow momoi's step. I quit and restart mozilla about
10 times now, still I haven't get a crash. My email address is always in the
collected addressd book.
Comment 24•25 years ago
|
||
One thing that occurs to me is that I normally select
the last msg in the thread and have it displayed
before startig to compose a new one. And once the new arrives
I would select the new one without messing with the scroll
bar or any other part of the UI.
Comment 25•25 years ago
|
||
momoi, did you try on sending message to yourslf instead of from other account?
I always send it to myself since I only set up one account so far. Can you try
sending and reading in the same account?
Comment 26•25 years ago
|
||
That's what I'm doing -- sending it to myself.
I understand huang can help demo this for you.
Reporter | ||
Comment 27•25 years ago
|
||
Yes. I try to read the mail which sending from the same account and crashed.
Reporter | ||
Comment 28•25 years ago
|
||
OK. I am trying to narrow down this problem...
If I send to different mail account, didn't get "first time" crash.
But if I send to the same mail account, it crashed at the first time.
Comment 29•25 years ago
|
||
Sol is running into this as well. Candice - can you go over to Karen's system
and view this? Karen - can you try to reproduce on Candice's system? It is
really easy to run into. Thanks.
Reporter | ||
Comment 30•25 years ago
|
||
Yes. She already knew that.
Comment 31•25 years ago
|
||
As far as M12 goes, this problem would only show up in a commercial build (which
does not get distributed on mozilla.org), so I do not think this should hold up
that boat.
Comment 32•25 years ago
|
||
Karan and I have tracked the way to reproduce it. Two key point
1. You have to hilight the lase message to diplay it.
2. In compose window, you have to hit Enter after type in the "to" field.
There's no crash if you didn't do both steps. It may have something to do with
the address widget or the name completion part. I'll keep look into it.
cc to Jean-Francois and David.
Reporter | ||
Updated•25 years ago
|
Summary: [DOGFOOD]Crashed when trying to read the send message from the messages thread pane → [DOGFOOD][PP]Crashed when trying to read the send message from the messages thread pane
Reporter | ||
Comment 33•25 years ago
|
||
I verified on 12-16-12-M12 for Mac platform include the two steps which Candice
described above. The Mac without this problem. Add [PP] on the summary since
this problem did not happen on Mac platform. Problem only happened on Linux &
Windows.
Comment 34•25 years ago
|
||
please_see_patch_in_19461
Assignee | ||
Comment 35•25 years ago
|
||
I am looking at it too...
Assignee | ||
Comment 36•25 years ago
|
||
I am still building a windows build as this not appends with Mac.
We do two different operations when you press <enter> after typing the email
address:
1) Create a new row
2) auto complete the address
Can somebody try to disable one of those two operations to try to narrow it
down. For that you just need to apply the following modification in the file
chromes/messengercompose/content/default/addressingWidgetOverlay.xul and then
restart Mozilla (if the XUL cache is not turn off):
case 1) Remove creation of new row:
replace line 65: { AutoCompleteAddress(this); awReturnHit(this); }"/>
by: { AutoCompleteAddress(this); }"/>
case 2) Don't auto complete address:
replace line 65: { AutoCompleteAddress(this); awReturnHit(this); }"/>
by: { awReturnHit(this); }"/>
Comment 37•25 years ago
|
||
I'll try the xul files since I can't get a crash on my debug build. I did look
at the patch for 19461, but the function for the patch never get called either
in bug 19461 or here and the patch did get called in the database destructor.
I'll look more on it.
Comment 38•25 years ago
|
||
ok, case 1 caused the crash. So display the last message(related to adding the
sender to collected address book) and autocompletion will cause the crash. Keep
looking...
Assignee | ||
Comment 39•25 years ago
|
||
Did you try case 2 also?
Comment 40•25 years ago
|
||
Yes, case 2 is fine.
Assignee | ||
Comment 41•25 years ago
|
||
good, very good. I rather prefer to have to debug something in auto complete
than in the tree widget. Does somebody reproduce the bug with a debug build?
Reporter | ||
Comment 42•25 years ago
|
||
Good News!!
It seems the commercial build for today's 12-17-10-M12 works fine now for Linux
now....maybe somebody fixed something else and fixed this bug as well.
If this problem not happened for the latest build, then Candice may mark "Fix"
as well since this is reproducable from the previous build, but already fixed
for the latest M12 commercial build already. I didn't try WinNT yet!!
Assignee | ||
Comment 43•25 years ago
|
||
Not so good! I reproduce the crash with the M13 build from today (build
1999121708). Unfortunally is not a debug build...
Assignee | ||
Comment 44•25 years ago
|
||
Seems to have a relation with AIM. That may explain while we don't reproduce
this bug witha debug build which is atleast for me a Mozilla build without AIM!
Comment 45•25 years ago
|
||
Me, too. Win32 32 1999121712 build crashes under the known
scenario.
Reporter | ||
Comment 46•25 years ago
|
||
OK. Anyway...this is M13 bug now. I will try to reproduce on M13 commercial
build after I complate the M12 testing.
Assignee | ||
Comment 47•25 years ago
|
||
I have just reproduced the crash with a Mac Commercial debug build. Now we can
start working... Something wrong between MsgCompose/AIM/Addressbook, nice
cocktail.
Comment 48•25 years ago
|
||
Jean-Francois, can you try my patch with your reproducible case?
Comment 49•25 years ago
|
||
I'll try to build a commercial debug build on my NT. Debug or release mozilla
build can't get the crash.
Assignee | ||
Comment 50•25 years ago
|
||
We crash in nsAddrDatabase::GetCardForEmailAddress when executing the line:
mdb_err result = GetStore()->FindRow(GetEnv(), m_CardRowScopeToken,
m_PriEmailColumnToken, &emailAddressYarn, &outRowId,
&cardRow);
Comment 51•25 years ago
|
||
Is this with or without my patch?
Assignee | ||
Comment 52•25 years ago
|
||
We crash when we check the second email address (I presume the destination address) because GetStore return
nsnull.
It was witjout your patch. I will take a look at your patch now.
Assignee | ||
Comment 53•25 years ago
|
||
One think before I look at the patch: Apparently, somebody close the DB before we are done with it?
Comment 54•25 years ago
|
||
yes, that's what's going on.
Assignee | ||
Comment 55•25 years ago
|
||
David, your patch doesn't fix the problem.
Here is what append so far:
When you display the message the first time, AIM open the address book DB and keep a pointer to it. Then when you
compose the message, autocompletion open also the DB and then close it (does that only the first time you use
autocomplete). Then later when we receive the message and try to diaplay it, AIM need to acces again the DB. As the
pointer on the DB still there, it doesn't open the DB again but just try to access it but as the srote is null, we crash!
Q: how come somebdy can close a DB used by somebody else? can we prevent that?
Q: how can we test is the db still open?
Assignee | ||
Comment 56•25 years ago
|
||
Q: Does AIM keep the DB open?
Q: Can we implement ingremental Open/Close to avoid closing the DB when somebody else use it?
Comment 57•25 years ago
|
||
AIM opens the DB and does not close it, but it looks as though we have no control
over others closing it.
Is there a way for me to check if the db is open or closed? If not, should I be
explicitly opening the db each time?
Assignee | ||
Comment 58•25 years ago
|
||
I think we should be able to support several customer (AIM, AB, AC) working in the same db at the same time.
Therefore we need to avoid closing the DB when it still in use.
BTW, AIM close the DB in its destructor.
Comment 59•25 years ago
|
||
Yep - you're right, but this destructor only gets called on quit.
Assignee | ||
Comment 60•25 years ago
|
||
The ugly solution for now would be to check the store. If is't null, then reopen the DB. Or just d'ont keep the DB open
all the time! David would be the best person to talk with about this dilemma
Comment 61•25 years ago
|
||
The way it should work is that Close() should just do a commit, and not close
the underlying store. The underlying store should be closed when the db ref
count goes to 0. This is the way the msg db works.
Assignee | ||
Comment 62•25 years ago
|
||
Ok, I can try to do that... or maybe Candice can do it?
Comment 63•25 years ago
|
||
Another way for you to fix this is to call Commit, and don't call Close (just
release your ref). Close is dangerous as written in the current address database
code, because it closes the db's out from under anyone else who has the db open.
But then you might not truly close the db, because the store doesn't get closed
when the ref-count goes to 0. I think this should be reworked.
Comment 64•25 years ago
|
||
I'd be happy to send you a patch of how I think it should be. Let me know.
Comment 65•25 years ago
|
||
Someone should probably search for all cases where the ab is getting closed right
now and review if those cases should actually be commits.
The fix for this particular bug involves changing the Close() call in the
autocomplete code, not in the AIM code, correct?
Comment 66•25 years ago
|
||
I'm proposing changing the implementation of nsAddrDatabase::Close to just do a
commit. Then, we should go through the code replacing Close's with Commit's, and
remove Close, so it's not confusing for people. The original implementation of
Close did a release ref, but we can't do that anymore. So close is superfluous.
Assignee | ||
Comment 67•25 years ago
|
||
Either AIM or AC are just readung the DB, therefore doing a commit doesn't have sense. AC open the DB then read all
the addresses and then Close it, I think it's a totally normal and safe way to use the DB.
Assignee | ||
Comment 68•25 years ago
|
||
I just did what bienvenue propose. I may have miss some thing but so far no more crash. Patch coming...
Assignee | ||
Comment 69•25 years ago
|
||
Comment 70•25 years ago
|
||
OK, that looks better to me. Can you verify that the destructor gets called, so
we can make sure the db gets closed?
Assignee | ||
Updated•25 years ago
|
Assignee: chuang → ducarroz
Assignee | ||
Comment 71•25 years ago
|
||
Amusil, whatever is the fix, you should always check if the store is not null before using it. It's better to not have
this little AIM feature than bringing down the whole application: Can you do that?
I reassign this bug to myself has I have the fix.
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 72•25 years ago
|
||
bienvenu, I've played a little bit with AB, I tried all the cases (AB edition, AC, AIM) and so far it works fine for me,
the DB is release correctly when we quit the application (only during the quit as AIM keept the DB open all the time).
Assignee | ||
Comment 73•25 years ago
|
||
bienvenu, can you officially review the fix?
Comment 74•25 years ago
|
||
Yes, I can add a check for a null store.
Comment 75•25 years ago
|
||
looks good.
Assignee | ||
Comment 76•25 years ago
|
||
Yes, please do it. It is possible than someone call ForceClose() to close the DB even is someone else still using it. It
this case we will crash if you are not testing the store.
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] → [PDT+] Have the fix, seeking for approval
Assignee | ||
Updated•25 years ago
|
Whiteboard: [PDT+] Have the fix, seeking for approval → [PDT+] Fix approved. Waiting on Tinderbox for checking
Assignee | ||
Comment 77•25 years ago
|
||
fix Approved by chofmann
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] Fix approved. Waiting on Tinderbox for checking → [PDT+]
Assignee | ||
Comment 78•25 years ago
|
||
Fixed and checked in.
Comment 79•25 years ago
|
||
*** Bug 22238 has been marked as a duplicate of this bug. ***
Reporter | ||
Comment 80•25 years ago
|
||
Lisa, from above ducarroz's comments that this bug has been fixed for build M13.
But this problem still happened for today's M12 12-20-12-M12 commercial build.
Do we still release M12 commercial build with this problem?
Comment 81•25 years ago
|
||
Chris H., how about this for M12?
I understand that there migh be another build tomorrow?
If there is yet another respin, why not put this fix in?
Comment 82•25 years ago
|
||
we are done with m12. last builds were spun tonight.
on to m13.
Comment 83•25 years ago
|
||
Karen - can you verify this in M13? Thanks.
Reporter | ||
Comment 84•25 years ago
|
||
Yes. I am trying to verify this problem now...
Reporter | ||
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Whiteboard: [PDT+] → [PDT+] Verified on all platforms
Reporter | ||
Comment 85•25 years ago
|
||
Verified on the Linux 12-23-08-M13 commercial build
Verified on the WinNT 12-23-09-M13 commercial build
Verified on the Mac 12-23-08-M13 commercial build
All platforms work OK for the M13 commercial build now...
Marking as Verified!!
Updated•20 years ago
|
Product: MailNews → Core
Updated•16 years ago
|
Product: Core → MailNews Core
You need to log in
before you can comment on or make changes to this bug.
Description
•