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)

defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: huang, Assigned: bugzilla)

References

Details

(Whiteboard: [PDT+] Verified on all platforms)

Attachments

(1 file)

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.
Status: NEW → ASSIGNED
Target Milestone: M13
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?
Syd - can you repro this on your Linux box?
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.
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
Assignee: ducarroz → chuang
Status: ASSIGNED → NEW
Whiteboard: [PDT+]
Putting on the PDT+ radar. Reassigning to chuang per phil's request.
OS: Linux → All
Hardware: PC → All
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?
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.
I'm having trouble reproducing this. What is the setup of AIM and the address book on your system, Huang?
huang - let me know when you're free for me to come by and check out the crash on your machine.
*** Bug 22013 has been marked as a duplicate of this bug. ***
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
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.
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.
Severity: major → blocker
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.
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.
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.
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.
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.
What I meant is that you need to quit Mozilla and re-start Mozilla/Mail.
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.
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.
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.
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?
That's what I'm doing -- sending it to myself. I understand huang can help demo this for you.
Yes. I try to read the mail which sending from the same account and crashed.
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.
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.
Yes. She already knew that.
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.
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.
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
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.
please_see_patch_in_19461
I am looking at it too...
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); }"/>
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.
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...
Did you try case 2 also?
Yes, case 2 is fine.
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?
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!!
Not so good! I reproduce the crash with the M13 build from today (build 1999121708). Unfortunally is not a debug build...
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!
Me, too. Win32 32 1999121712 build crashes under the known scenario.
OK. Anyway...this is M13 bug now. I will try to reproduce on M13 commercial build after I complate the M12 testing.
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.
Jean-Francois, can you try my patch with your reproducible case?
I'll try to build a commercial debug build on my NT. Debug or release mozilla build can't get the crash.
We crash in nsAddrDatabase::GetCardForEmailAddress when executing the line: mdb_err result = GetStore()->FindRow(GetEnv(), m_CardRowScopeToken, m_PriEmailColumnToken, &emailAddressYarn, &outRowId, &cardRow);
Is this with or without my patch?
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.
One think before I look at the patch: Apparently, somebody close the DB before we are done with it?
yes, that's what's going on.
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?
Q: Does AIM keep the DB open? Q: Can we implement ingremental Open/Close to avoid closing the DB when somebody else use it?
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?
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.
Yep - you're right, but this destructor only gets called on quit.
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
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.
Ok, I can try to do that... or maybe Candice can do it?
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.
I'd be happy to send you a patch of how I think it should be. Let me know.
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?
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.
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.
I just did what bienvenue propose. I may have miss some thing but so far no more crash. Patch coming...
Attached patch proposed patch by ducarroz (deleted) — Splinter Review
OK, that looks better to me. Can you verify that the destructor gets called, so we can make sure the db gets closed?
Assignee: chuang → ducarroz
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.
Status: NEW → ASSIGNED
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).
bienvenu, can you officially review the fix?
Yes, I can add a check for a null store.
looks good.
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.
Whiteboard: [PDT+] → [PDT+] Have the fix, seeking for approval
Whiteboard: [PDT+] Have the fix, seeking for approval → [PDT+] Fix approved. Waiting on Tinderbox for checking
fix Approved by chofmann
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] Fix approved. Waiting on Tinderbox for checking → [PDT+]
Fixed and checked in.
*** Bug 22238 has been marked as a duplicate of this bug. ***
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?
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?
we are done with m12. last builds were spun tonight. on to m13.
QA Contact: lchiang → huang
Karen - can you verify this in M13? Thanks.
Yes. I am trying to verify this problem now...
Status: RESOLVED → VERIFIED
Whiteboard: [PDT+] → [PDT+] Verified on all platforms
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!!
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: