34199 - removing a mailnews account causes infinite pref enumeration.

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Account Configuration, defect, P1)

Description

[(not reading, please use [e-mail] instead)]

when removing my first mailnews account, I go into an infinite loop.

calling EnumerateChildren never stops.

alecf / neeti, remember that bug I logged about infinite pref looping (when you 
enumerate over prefs?)  I think this is the same thing.

PL_HashString(const void * 0x023d7ee0) line 463 + 6 bytes
PL_HashTableLookup(PLHashTable * 0x024145f0, const void * 0x023d7ee0) line 343 + 
10 bytes
PREF_ClearUserPref(const char * 0x023d7ee0) line 1644 + 16 bytes
nsPref::ClearUserPref(nsPref * const 0x01002160, const char * 0x023d7ee0) line 
650 + 9 bytes
nsMsgIncomingServer::clearPrefEnum(const char * 0x023d7ee0, void * 0x01002160) 
line 876
pref_enumChild(PLHashEntry * 0x023d6350, int 9564870, void * 0x0012c640) line 
987 + 20 bytes
PL_HashTableEnumerateEntries(PLHashTable * 0x024145f0, int (PLHashEntry *, int, 
void *)* 0x012f7740 pref_enumChild(PLHashEntry *, int, void *), void * 
0x0012c640) line 368 + 15 bytes
nsPref::EnumerateChildren(nsPref * const 0x01002160, const char * 0x0012c680, 
void (const char *, void *)* 0x026d1677 nsMsgIncomingServer::clearPrefEnum(char 
const *,void *), void * 0x01002160) line 999 + 21 bytes
nsMsgIncomingServer::ClearAllValues(nsMsgIncomingServer * const 0x036dede0) line 
828 + 43 bytes
nsMsgAccountManager::RemoveAccount(nsMsgAccountManager * const 0x036c67f0, 
nsIMsgAccount * 0x036dd460) line 549
XPTC_InvokeByIndex(nsISupports * 0x036c67f0, unsigned int 5, unsigned int 1, 
nsXPTCVariant * 0x0012c980) line 139
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext * 0x039646c0, 
nsXPCWrappedNative * 0x03a4e5b0, const XPCNativeMemberDescriptor * 0x036d047c, 
nsXPCWrappedNativeClass::CallMode CALL_METHOD, unsigned int 1, long * 
0x02215d80, long * 0x0012cb24) line 898 + 43 bytes
WrappedNative_CallMethod(JSContext * 0x039646c0, JSObject * 0x02248b18, unsigned 
int 1, long * 0x02215d80, long * 0x0012cb24) line 200 + 34 bytes
js_Invoke(JSContext * 0x039646c0, unsigned int 1, unsigned int 0) line 679 + 23 
bytes
js_Interpret(JSContext * 0x039646c0, long * 0x0012d448) line 2457 + 15 bytes
js_Invoke(JSContext * 0x039646c0, unsigned int 1, unsigned int 2) line 695 + 13 
bytes
js_InternalInvoke(JSContext * 0x039646c0, JSObject * 0x02248c28, long 36211840, 
unsigned int 0, unsigned int 1, long * 0x0012d5d4, long * 0x0012d580) line 768 + 
19 bytes
JS_CallFunctionValue(JSContext * 0x039646c0, JSObject * 0x02248c28, long 
36211840, unsigned int 1, long * 0x0012d5d4, long * 0x0012d580) line 2794 + 31 
bytes
nsJSContext::CallEventHandler(nsJSContext * const 0x03965b10, void * 0x02248c28, 
void * 0x02288c80, unsigned int 1, void * 0x0012d5d4, int * 0x0012d5d0) line 730 
+ 33 bytes
nsJSEventListener::HandleEvent(nsIDOMEvent * 0x03fe3034) line 128 + 57 bytes
nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03a04440, 
nsIDOMEvent * 0x03fe3034, unsigned int 4, unsigned int 7) line 703 + 19 bytes
nsEventListenerManager::HandleEvent(nsIPresContext * 0x039b8420, nsEvent * 
0x0012db08, nsIDOMEvent * * 0x0012dad0, unsigned int 7, nsEventStatus * 
0x0012de28) line 843 + 29 bytes
nsXULElement::HandleDOMEvent(nsXULElement * const 0x03a04590, nsIPresContext * 
0x039b8420, nsEvent * 0x0012db08, nsIDOMEvent * * 0x0012dad0, unsigned int 1, 
nsEventStatus * 0x0012de28) line 3207
nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 
0x03a2ad20, nsIPresContext * 0x039b8420, nsMouseEvent * 0x0012df1c, 
nsEventStatus * 0x0012de28) line 1587 + 42 bytes
nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x03a2ad20, 
nsIPresContext * 0x039b8420, nsGUIEvent * 0x0012df1c, nsIFrame * 0x02277c34, 
nsEventStatus * 0x0012de28, nsIView * 0x039b9ad0) line 757 + 24 bytes
PresShell::HandleEvent(PresShell * const 0x039b94e4, nsIView * 0x039b9ad0, 
nsGUIEvent * 0x0012df1c, nsEventStatus * 0x0012de28, int & 1) line 3455 + 43 
bytes
nsView::HandleEvent(nsView * const 0x039b9ad0, nsGUIEvent * 0x0012df1c, unsigned 
int 28, nsEventStatus * 0x0012de28, int & 1) line 811
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x039b9cb0, nsGUIEvent * 
0x0012df1c, nsEventStatus * 0x0012de28) line 1349
HandleEvent(nsGUIEvent * 0x0012df1c) line 69
nsWindow::DispatchEvent(nsWindow * const 0x039b99a4, nsGUIEvent * 0x0012df1c, 
nsEventStatus & nsEventStatus_eIgnore) line 498 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012df1c) line 519
nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3081 + 
21 bytes
ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 
3288
nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 22151263, long * 
0x0012e1e8) line 2273 + 24 bytes
nsWindow::WindowProc(HWND__ * 0x001905b4, unsigned int 514, unsigned int 0, long 
22151263) line 676 + 27 bytes
USER32! 77e71820()

Comment 1

[(not reading, please use [e-mail] instead)]

doesn't have to be the first mailnews account.

Comment 2

[Alec Flett]

doh! this is bad.
I have some idea why this might be happening - we're probably trying to
reconstruct the list of accounts and some how tweaking an account pref every
time.

Comment 3

[Alec Flett]

*** Bug 33538 has been marked as a duplicate of this bug. ***

Comment 4

[Alec Flett]

*** Bug 32716 has been marked as a duplicate of this bug. ***

Comment 5

[selmer (gone)]

Mass moving to M16 to get these off the M15 radar.  Please let me know if this
is really an M15 stopper.

Comment 6

[Alec Flett]

I believe this is a stopper - you can't delete a mail account with this bug.
it's what I'm working on right now, hope to have a fix by end of day wednesday

Comment 7

[Alec Flett]

fix is now in hand. having sspitzer review it.
the fix fixes all pref-enumeration related bugs too.

Comment 8

[Alec Flett]

fix is in.

Comment 9

[Ninoschka Baca]

Build 2000-04-06-10M15: NT4
I tried the scenario in bug# 33538 and can now delete the 1st and 2nd news 
account without the application freezing. 

(Once slight focus problem. After deleting the 2nd news account, the Account 
Settings dialog moves behind the 3-pane window. After selecting OK in the 
Confirm dialog then Account Settings moves to the front. 

Expected Results: After deleting the News account then the Confirmation dialog 
should appear ontop of the Account Settings dialog, not infront of the 3-pane.
Should I log another bug?

Comment 10

[Ninoschka Baca]

[e-mail]: Can you try your scenario again using the latest builds (4/6 or 
4/7)?

Comment 11

[Brian Krabbe]

I tried it out with with the 4/7 nightly and it deleted my account 
properly...great work!

Comment 12

[Ninoschka Baca]

Verified.

Seth, if you see a problem then just reopen but it looks ok for now.