Closed Bug 30666 Opened 25 years ago Closed 25 years ago

core dump when cancelling imap logon

Categories

(MailNews Core :: Networking, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: con.hennessy, Assigned: warrensomebody)

References

Details

(Keywords: smoketest)

With todays CVS update when I cancel loggin onto my IMAP server, there is a core dump. Also when I entered incorrect data for my username it also results in a core dump when I try to logon.
this is not an account manager problem, this is an IMAP problem
Assignee: alecf → bienvenu
Component: Account Manager → Networking-Mail
imap hasn't changed. looks more like an event queue problem. Either dougt or warren's changes, or maybe danm? Beats me. Looks like dougt got backed out, so it's probably not him. I"m guessing warren, but I'll look into danm's changes. Looks like a stack overflow. nsComponentManagerImpl::ProgIDToClassID(nsComponentManagerImpl * const 0x010a4530, const char * 0x100b5a44, nsID * 0x000330e0) line 1148 + 3 bytes nsComponentManager::ProgIDToClassID(const char * 0x100b5a44, nsID * 0x000330e0) line 59 nsServiceManagerImpl::GetService(nsServiceManagerImpl * const 0x010a48a0, const char * 0x100b5a44, const nsID & {...}, nsISupports * * 0x00033150, nsIShutdownListener * 0x00000000) line 435 + 13 bytes nsServiceManager::GetService(const char * 0x100b5a44, const nsID & {...}, nsISupports * * 0x00033150, nsIShutdownListener * 0x00000000) line 551 nsGetServiceByProgID::operator()(const nsID & {...}, void * * 0x00033150) line 63 + 22 bytes nsCOMPtr<nsIObserverService>::assign_from_helper(const nsCOMPtr_helper & {...}, const nsID & {...}) line 795 + 18 bytes nsCOMPtr<nsIObserverService>::nsCOMPtr<nsIObserverService>(const nsCOMPtr_helper & {...}) line 498 nsEventQueueImpl::NotifyObservers(const char * 0x100b5818) line 166 + 33 bytes nsEventQueueImpl::~nsEventQueueImpl() line 84 nsEventQueueImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsEventQueueImpl::Release(nsEventQueueImpl * const 0x03a31d00) line 139 + 120 bytes nsCOMPtr<nsIEventQueue>::~nsCOMPtr<nsIEventQueue>() line 435 nsAppShellService::Observe(nsAppShellService * const 0x0143a9f4, nsISupports * 0x03a31d00, const unsigned short * 0x000333b0, const unsigned short * 0x00000000) line 759 nsObserverService::Notify(nsObserverService * const 0x0143a230, nsISupports * 0x03a31d00, const unsigned short * 0x000333b0, const unsigned short * 0x00000000) line 241 nsEventQueueImpl::NotifyObservers(const char * 0x100b5818) line 169 nsEventQueueImpl::~nsEventQueueImpl() line 84 nsEventQueueImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsEventQueueImpl::Release(nsEventQueueImpl * const 0x03a31d00) line 139 + 120 bytes nsCOMPtr<nsIEventQueue>::~nsCOMPtr<nsIEventQueue>() line 435 nsAppShellService::Observe(nsAppShellService * const 0x0143a9f4, nsISupports * 0x03a31d00, const unsigned short * 0x000335b8, const unsigned short * 0x00000000) line 759 nsObserverService::Notify(nsObserverService * const 0x0143a230, nsISupports * 0x03a31d00, const unsigned short * 0x000335b8, const unsigned short * 0x00000000) line 241 nsEventQueueImpl::NotifyObservers(const char * 0x100b5818) line 169 nsEventQueueImpl::~nsEventQueueImpl() line 84 nsEventQueueImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsEventQueueImpl::Release(nsEventQueueImpl * const 0x03a31d00) line 139 + 120 bytes nsCOMPtr<nsIEventQueue>::~nsCOMPtr<nsIEventQueue>() line 435 nsAppShellService::Observe(nsAppShellService * const 0x0143a9f4, nsISupports * 0x03a31d00, const unsigned short * 0x000337c0, const unsigned short * 0x00000000) line 759 nsObserverService::Notify(nsObserverService * const 0x0143a230, nsISupports * 0x03a31d00, const unsigned short * 0x000337c0, const unsigned short * 0x00000000) line 241 nsEventQueueImpl::NotifyObservers(const char * 0x100b5818) line 169 nsEventQueueImpl::~nsEventQueueImpl() line 84 nsEventQueueImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsEventQueueImpl::Release(nsEventQueueImpl * const 0x03a31d00) line 139 + 120 bytes nsCOMPtr<nsIEventQueue>::~nsCOMPtr<nsIEventQueue>() line 435 nsAppShellService::Observe(nsAppShellService * const 0x0143a9f4, nsISupports * 0x03a31d00, const unsigned short * 0x000339c8, const unsigned short * 0x00000000) line 759 nsObserverService::Notify(nsObserverService * const 0x0143a230, nsISupports * 0x03a31d00, const unsigned short * 0x000339c8, const unsigned short * 0x00000000) line 241 nsEventQueueImpl::NotifyObservers(const char * 0x100b5818) line 169 nsEventQueueImpl::~nsEventQueueImpl() line 84 nsEventQueueImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsEventQueueImpl::Release(nsEventQueueImpl * const 0x03a31d00) line 139 + 120 bytes nsCOMPtr<nsIEventQueue>::~nsCOMPtr<nsIEventQueue>() line 435
Assignee: bienvenu → warren
Here's the top of the stack, I believe. Once we get into the appshell service observer stuff, that's when we start to auger in, I believe. nsAppShellService::Observe(nsAppShellService * const 0x0143a9f4, nsISupports * 0x03cb85e0, const unsigned short * 0x0012f1b0, const unsigned short * 0x00000000) line 749 nsObserverService::Notify(nsObserverService * const 0x0143a230, nsISupports * 0x03cb85e0, const unsigned short * 0x0012f1b0, const unsigned short * 0x00000000) line 241 nsEventQueueImpl::NotifyObservers(const char * 0x100b5818) line 169 nsEventQueueImpl::~nsEventQueueImpl() line 84 nsEventQueueImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsEventQueueImpl::Release(nsEventQueueImpl * const 0x03cb85e0) line 139 + 120 bytes nsWebShell::~nsWebShell() line 626 + 36 bytes nsWebShell::`scalar deleting destructor'(unsigned int 1) + 15 bytes nsDocShell::Release(nsDocShell * const 0x03cbc740) line 123 + 119 bytes nsWebShell::Release(nsWebShell * const 0x03cbc740) line 730 + 12 bytes nsCOMPtr<nsIDocShellTreeItem>::~nsCOMPtr<nsIDocShellTreeItem>() line 435 GlobalWindowImpl::OpenInternal(GlobalWindowImpl * const 0x02746940, JSContext * 0x027448a0, long * 0x02588e88, unsigned int 4, int 1, nsIDOMWindow * * 0x0012f740) line 2447 + 51 bytes GlobalWindowImpl::OpenDialog(GlobalWindowImpl * const 0x02746948, JSContext * 0x027448a0, long * 0x02588e88, unsigned int 4, nsIDOMWindow * * 0x0012f740) line 1535 nsCommonDialogs::DoDialog(nsCommonDialogs * const 0x0302b510, nsIDOMWindow * 0x02746948, nsIDialogParamBlock * 0x03cbcc40, const char * 0x015e7cac) line 421 + 29 bytes nsCommonDialogs::UniversalDialog(nsCommonDialogs * const 0x0302b510, nsIDOMWindow * 0x02746948, const unsigned short * 0x00000000, const unsigned short * 0x03cb8890, const unsigned short * 0x03cba780, const unsigned short * 0x03cbceb0, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, ...) lin nsWebShellWindow::UniversalDialog(nsWebShellWindow * const 0x0278316c, const unsigned short * 0x00000000, const unsigned short * 0x03cb8890, const unsigned short * 0x03cba780, const unsigned short * 0x03cbceb0, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * ...) line nsNetSupportDialog::UniversalDialog(nsNetSupportDialog * const 0x03025cc0, const unsigned short * 0x00000000, const unsigned short * 0x03cb8890, const unsigned short * 0x03cba780, const unsigned short * 0x03cbceb0, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * 0x00000000, const unsigned short * ...) l si_CheckGetPassword(unsigned short * * 0x0012fc5c, const unsigned short * 0x03cba780, int * 0x0012fab0) line 180 + 71 bytes SINGSIGN_PromptPassword(const unsigned short * 0x03cba780, unsigned short * * 0x0012fc5c, const char * 0x03cb9fb0, nsIPrompt * 0x0278042c, int * 0x0012fc64, int 0) line 2664 + 20 bytes nsWalletlibService::PromptPasswordURL(nsWalletlibService * const 0x02787e50, const unsigned short * 0x03cba780, unsigned short * * 0x0012fc5c, const char * 0x03cb9fb0, int 0, nsIPrompt * 0x0278042c, int * 0x0012fc64) line 116 + 29 bytes nsWebShellWindow::PromptPassword(nsWebShellWindow * const 0x02780430, const char * 0x03cb9fb0, int 0, const unsigned short * 0x03cb8940, const unsigned short * 0x03cba780, unsigned short * * 0x0012fc5c, int * 0x0012fc64) line 2176 + 52 bytes nsMsgIncomingServer::GetPasswordWithUI(nsMsgIncomingServer * const 0x030562d0, const unsigned short * 0x03cba780, const unsigned short * 0x03cb8940, nsIMsgWindow * 0x03038690, char * * 0x03a2fe40) line 597 + 84 bytes nsImapIncomingServer::PromptForPassword(nsImapIncomingServer * const 0x03056310, char * * 0x03a2fe40, nsIMsgWindow * 0x03038690) line 1396 + 32 bytes XPTC_InvokeByIndex(nsISupports * 0x03056310, unsigned int 17, unsigned int 2, nsXPTCVariant * 0x03cba5f0) line 139 EventHandler(PLEvent * 0x03cba640) line 481 + 41 bytes PL_HandleEvent(PLEvent * 0x03cba640) line 556 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x0143a410) line 501 + 9 bytes _md_EventReceiverProc(HWND__ * 0x020707d0, unsigned int 49487, unsigned int 0, long 21210128) line 1011 + 9 bytes USER32! 77e71820()
adding self to cc-list.
If I back out warren's change to nsEventQueue.cpp, this crash goes away.
The problem is that nsEventQueues were changed to use the new NS_IMPL_THREADSAFE macros, rather than the older, presumably unsafe ones. NS_IMPL_RELEASE bumps mRefCnt to 1 after it hits 0, before the fireworks start. ...THREADSAFE... doesn't do that. There's a (actually no longer necessary) sequence of events during event queue destruction where it references itself with nsCOMPtrs, so it's clenching and unclenching as it winds down, and the initial refcount of 0 is causing it to reenter its destructor. Warren, you just need to add the mRefCnt = 1 line, as it is in NS_IMPL_RELEASE.
ah, thanks, Dan - I was just going to see how NS_IMPL_THREADSAFE_ISUPPORTS2 was different from NS_IMPL_ISUPPORTS2
*** Bug 30636 has been marked as a duplicate of this bug. ***
*** Bug 30599 has been marked as a duplicate of this bug. ***
I'm confirming this bug given the comments and the fact that confirmed bug 30599 was closed as a duplicate of this one.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Actually both linux and win32 has this problem see bug http://bugzilla.mozilla.org/show_bug.cgi?id=30693
marking a smoketest blocker, i imagine this is similar to the crash-on-second-password-dialog blocker.
Severity: normal → blocker
Keywords: smoketest
Whiteboard: building with the suggested fix. will check in if it works.
*** Bug 30693 has been marked as a duplicate of this bug. ***
This affects aim as well anytime an activity dialog is invoked more than one time in a row and the OK button is clicked. (i.e...in aim it crashed when invoking Add group or delete group more than once. It also occurred in Address book editing more than two cards in a row after clicking OK to the second edit card dialog.)
*** Bug 30720 has been marked as a duplicate of this bug. ***
*** Bug 30720 has been marked as a duplicate of this bug. ***
Latest duplication's case is when clicking Stop during newsgroup header download. OK the alert which appears "unknown error" and crash results.
QA Contact: lchiang → laurel
added mRefCnt = 1 to NS_IMPL_THREADSAFE_RELEASE
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: building with the suggested fix. will check in if it works.
*** Bug 30748 has been marked as a duplicate of this bug. ***
*** Bug 30749 has been marked as a duplicate of this bug. ***
The problem mentioned in bug 30636 is still happening. I still crash when trying to enter a master password.
shrir: First, are you really up to date? (Be careful that Windows dependencies don't work, so if you just pulled the new header you have to clobber -- sorry). Second, you should comment in bug 30636 if that problem is separate from this one. (But I can't see how they'd be different off hand.)
I agree with Warren, you probably didn't clobber and rebuild. Recall that the change is to a .h file and that is used in many other directories. I've picked up the fix that danm made, clobbered, rebuilt, and no longer see the crash on setting the master password.
shrir is using the commercial release build off sweetlou. It's okay on the mozilla builds, so either there was a build problem or it's a commercial only problem, which seems unlikely.
Yes, I confirmed with Esther and she also is seeing the problem only on the Linux commercial bits. Mozilla bits do not show this problem.
Leaf was also having problems with the commercial build after building with the mozilla fix. I've done a nuke-from-orbit commercial build and don't see the problem. Current thought is that something unspecified went oddly wrong. We're waiting for tomorrow's release build and hoping it'll be better.
*** Bug 30728 has been marked as a duplicate of this bug. ***
*** Bug 30730 has been marked as a duplicate of this bug. ***
*** Bug 30774 has been marked as a duplicate of this bug. ***
OK, I've verified this is ok. I've verified no crash in the scenarios for the following bugs using today's commercial builds on linux rh6.0 and NT 4.0. I've verified a subset so far on mac OS 9.0, so will mark this verified. OK cacelling imap login. 30636 OK 30599 OK 30693 OK 30720 OK 30748 OK 30749 OK 30728 OK 30730 OK 30774 OK
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.