30693 - Crash, at Login Failed when you give a bad password

Status: VERIFIED DUPLICATE of bug 30666

(MailNews Core :: Networking, defect, P1)

Description

[esther]

Uisng build 2000-03-05-17 on win98, if you give a bad password, you get the 
login failed error and then a crash.  Still need to  test on linux and mac.

1. Launch Browser
2. Launch mail using Tasks|Mail  
3. If IMAP account is first you will get a password dialog.  Enter the wrong 
password
Result: Login Failed error comes up and then you crash 
Expected: To have the Password dialog come up again for a 2nd try.
4. If POP account is first
5. Click Get Msg, Enter the wrong password.
6. An error message comes up "An error occurred while sending your password to 
the server..."  Click OK   
Result: Crash
Expected:  To have the Password dialog come up again for a 2nd try.

Comment 1

[esther]

Happens on linux build 2000-03-06-08 too.  Talkback report for windows was 
submitted waiting for it to show up in report.  Changing platform to all

Comment 2

[esther]

Mac, is OK using build 2000-03-05-08 commercial and 2000-03-06-08 mozilla.

Comment 3

[esther]

Additional scenario:  Crash also, giving correct password to 2nd account after 
giving correct password to 1st account.

Comment 4

[Charles Wang]

Even I gave the right passwords for both IMAP and POP, they crashed. But if 
restarted the system again, IMAP works fine.

Comment 5

[Daniel (Leaf) Nunes]

marking as smoketest blocker

Comment 6

[Scott MacGregor]

bienvenu says this is a dup of a bug warren has....

Comment 7

[Sammy Ford]

A stack trace i got, i was able to initially get my mail, but as soon as it was
done, i crashed with this. both correct/incorrect passwd. Im on linux, so it may
be the threading stuff warren checked in, im cc'ing him as well.

#0  0x365c09 in __pthread_lock (lock=0x0, self=0x805bd10) at spinlock.c:41
#1  0x36313b in __pthread_mutex_lock (mutex=0x805bd10) at mutex.c:84
#2  0x33e261 in PR_Lock (lock=0x805bd10) at ptsynch.c:167
#3  0x24b5e5 in nsHashtable::Get (this=0x805b8c0, aKey=0xbfe0214c)
    at nsHashtable.cpp:166
#4  0x283fe3 in nsComponentManagerImpl::ProgIDToClassID (this=0x805aeb0,
    aProgID=0x2d9220 "component://netscape/observer-service",
    aClass=0xbfe0224c) at nsComponentManager.cpp:1149
#5  0x28e2e2 in nsComponentManager::ProgIDToClassID (
    aProgID=0x2d9220 "component://netscape/observer-service",
    aClass=0xbfe0224c) at nsRepository.cpp:58
#6  0x28fa50 in nsServiceManagerImpl::GetService (this=0x805a970,
    aProgID=0x2d9220 "component://netscape/observer-service", aIID=@0x2dff88,
    result=0xbfe02308, shutdownListener=0x0) at nsServiceManager.cpp:429
#7  0x28feca in nsServiceManager::GetService (
    aProgID=0x2d9220 "component://netscape/observer-service", aIID=@0x2dff88,
    result=0xbfe02308, shutdownListener=0x0) at nsServiceManager.cpp:544
#8  0x28eb73 in nsGetServiceByProgID::operator() (this=0xbfe02378,
    aIID=@0x2dff88, aInstancePtr=0xbfe02308) at nsServiceManager.cpp:63
#9  0x2ba0b3 in nsCOMPtr<nsIObserverService>::assign_from_helper (
    this=0xbfe02388, helper=@0xbfe02378, aIID=@0x2dff88)
    at ../../dist/include/nsCOMPtr.h:795
#10 0x2ba35f in nsCOMPtr<nsIObserverService>::nsCOMPtr (this=0xbfe02388,
---Type <return> to continue, or q <return> to quit---
    helper=@0xbfe02378) at ../../dist/include/nsCOMPtr.h:497
#11 0x29567e in nsEventQueueImpl::NotifyObservers (this=0x8bc0208,
    aTopic=0x2d8fbf "nsIEventQueueDestroyed") at nsEventQueue.cpp:166
#12 0x2950a2 in nsEventQueueImpl::~nsEventQueueImpl (this=0x8bc0208,
    __in_chrg=3) at nsEventQueue.cpp:83
#13 0x295443 in nsEventQueueImpl::Release (this=0x8bc0208)
    at nsEventQueue.cpp:137
#14 0x2c7c17 in nsCOMPtr<nsIEventQueue>::~nsCOMPtr (this=0xbfe024f4,
    __in_chrg=2) at ../../../dist/include/nsCOMPtr.h:434
#15 0x783cff in ?? ()
   from /home/sford/mozilla/dist/bin/components/libnsappshell.so
#16 0x24ed89 in nsObserverService::Notify (this=0x812d048, aSubject=0x8bc0208,
    aTopic=0xbfe02648, someData=0x0) at nsObserverService.cpp:239
#17 0x295703 in nsEventQueueImpl::NotifyObservers (this=0x8bc0208,
    aTopic=0x2d8fbf "nsIEventQueueDestroyed") at nsEventQueue.cpp:168
#18 0x2950a2 in nsEventQueueImpl::~nsEventQueueImpl (this=0x8bc0208,
    __in_chrg=3) at nsEventQueue.cpp:83
#19 0x295443 in nsEventQueueImpl::Release (this=0x8bc0208)
    at nsEventQueue.cpp:137
#20 0x2c7c17 in nsCOMPtr<nsIEventQueue>::~nsCOMPtr (this=0xbfe02794,
    __in_chrg=2) at ../../../dist/include/nsCOMPtr.h:434
#21 0x783cff in ?? ()
   from /home/sford/mozilla/dist/bin/components/libnsappshell.so
---Type <return> to continue, or q <return> to quit---
#22 0x24ed89 in nsObserverService::Notify (this=0x812d048, aSubject=0x8bc0208,
    aTopic=0xbfe028e8, someData=0x0) at nsObserverService.cpp:239
#23 0x295703 in nsEventQueueImpl::NotifyObservers (this=0x8bc0208,
    aTopic=0x2d8fbf "nsIEventQueueDestroyed") at nsEventQueue.cpp:168
#24 0x2950a2 in nsEventQueueImpl::~nsEventQueueImpl (this=0x8bc0208,
    __in_chrg=3) at nsEventQueue.cpp:83
#25 0x295443 in nsEventQueueImpl::Release (this=0x8bc0208)
    at nsEventQueue.cpp:137
#26 0x2c7c17 in nsCOMPtr<nsIEventQueue>::~nsCOMPtr (this=0xbfe02a34,
    __in_chrg=2) at ../../../dist/include/nsCOMPtr.h:434
#27 0x783cff in ?? ()
   from /home/sford/mozilla/dist/bin/components/libnsappshell.so
#28 0x24ed89 in nsObserverService::Notify (this=0x812d048, aSubject=0x8bc0208,
    aTopic=0xbfe02b88, someData=0x0) at nsObserverService.cpp:239
#29 0x295703 in nsEventQueueImpl::NotifyObservers (this=0x8bc0208,
    aTopic=0x2d8fbf "nsIEventQueueDestroyed") at nsEventQueue.cpp:168
#30 0x2950a2 in nsEventQueueImpl::~nsEventQueueImpl (this=0x8bc0208,
    __in_chrg=3) at nsEventQueue.cpp:83
#31 0x295443 in nsEventQueueImpl::Release (this=0x8bc0208)
    at nsEventQueue.cpp:137

Comment 8

[esther]

Probably a dup of 30666, but that was logged for linux, this bug is for both 
linux and win, mac OK.  

Comment 9

[scalkins]

This affects aim as well. It occurs for us anytime two dialogs are invoked that 
do the same action. (2 add groups, delete groups in a row..etc.)CC amusil, prass 
and scalkins.

Comment 10

[Warren Harris]

We need to stabalize the refcnt in the threadsafe macros as well. Danm is 
working on the fix now.

*** This bug has been marked as a duplicate of 30666 ***

Comment 11

[esther]

Verified as duplicate