Closed
Bug 16551
Opened 25 years ago
Closed 25 years ago
[DOGFOOD] CRASH when migrating a profile on mac, (deleting EventQueueEntry object, and then trying to access it's mQueueStack by calling GetEventQueue())
Categories
(Core :: XPCOM, defect, P3)
Tracking
()
VERIFIED
FIXED
M11
People
(Reporter: sspitzer, Assigned: danm.moz)
References
Details
(Whiteboard: [PDT+])
this is only on the mac.
when I migrate a 4.x account (to test, remove your "Mozilla Registry" and run
"Mozilla Installer", select a 4.x account name, and hit Start) I crash.
make sure you have at least two 4.x profiles. (wiht just one, it automatically
migrates, and that may change things.)
dougt wrote the code for dbragg to do the profile migration progress dialog, so
assigning to me.
something is holding on to the EventQueueEntry object (nsEventQueueService.cpp),
but the refcount goes to 0, so the object is getting destroyed, and then
referenced and then boom.
perhaps its a refcount problem? (one too many releases?)
I'll post the stack in a few minutes.
I'll continue to debug, to see if there is an extra release in there.
for now, I'm going to check this in, as it prevents the crash.
but it's obviously not a real fix.
Index: nsEventQueueService.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpcom/threads/nsEventQueueService.cpp,v
retrieving revision 1.17
diff -p -r1.17 nsEventQueueService.cpp
*** nsEventQueueService.cpp 1999/08/23 10:11:03 1.17
--- nsEventQueueService.cpp 1999/10/15 21:39:04
*************** EventQueueEntry::~EventQueueEntry()
*** 84,89 ****
--- 84,91 ----
{
// Delete our stack
delete mQueueStack;
+ // XXX temporary horrible hack fix for bug #xxxxx
+ mQueueStack = NULL;
}
nsIEventQueue* EventQueueEntry::GetEventQueue(void)
Reporter | ||
Comment 1•25 years ago
|
||
here's the stack.
Calling chain using A6/R1 links
Back chain ISA Caller
00000000 PPC 0C5907C4
0D164E00 PPC 0C58CFB4 main+0013C
0D164D90 PPC 0C58C838 main1(int, char**)+00324
0D164C80 PPC 0C123C6C nsProfile::StartupWithArgs(nsICmdLineService*)+00084
0D164C10 PPC 0C124224 nsProfile::LoadDefaultProfileDir(nsCString&)+004D8
0D164B10 PPC 0C2A04E0 nsAppShellService::Run()+00020
0D164AD0 PPC 0C264704 nsAppShell::Run()+00050
0D164A50 PPC 0C265498 nsMacMessagePump::DoMessagePump()+00044
0D164A00 PPC 0C2656B0 nsMacMessagePump::DispatchEvent(int, EventRecord*)+
00098
0D1649B0 PPC 0C265F94 nsMacMessagePump::DoMouseUp(EventRecord&)+00050
0D164960 PPC 0C2664C8
nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort
*)+0004C
0D164910 PPC 0C25F8FC nsMacMessageSink::DispatchOSEvent(EventRecord&,
GrafPort*)+00048
0D1648D0 PPC 0C258EA4 nsMacWindow::HandleOSEvent(EventRecord&)+0004C
0D164870 PPC 0C259ADC nsMacEventHandler::HandleOSEvent(EventRecord&)+000D0
0D164820 PPC 0C25B4AC nsMacEventHandler::HandleMouseUpEvent(EventRecord&)+
000C4
0D164790 PPC 0C240ACC nsWindow::DispatchMouseEvent(nsMouseEvent&)+00060
0D164730 PPC 0C240A0C nsWindow::DispatchWindowEvent(nsGUIEvent&)+00028
0D1646F0 PPC 0C240918 nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus&
)+000A8
0D1646A0 PPC 0BB679E8 HandleEvent(nsGUIEvent*)+00064
0D164650 PPC 0BB64090 nsViewManager::DispatchEvent(nsGUIEvent*,
nsEventStatus&)+007C4
0D164470 PPC 0BB699EC nsView::HandleEvent(nsGUIEvent*, unsigned int,
nsEventStatus&, i
nt&)+001F0
0D1643F0 PPC 0BCDA47C PresShell::HandleEvent(nsIView*, nsGUIEvent*,
nsEventStatus&)+00
60C
0D164350 PPC 0BD8F638 nsEventStateManager::PostHandleEvent(nsIPresContext&
, nsGUIEvent
*, nsIFrame*, nsEventStatus&, nsIView*)+007D8
0D1641F0 PPC 0BD90DB0
nsEventStateManager::CheckForAndDispatchClick(nsIPresContext&, n
sMouseEvent*, nsEventStatus&)+00180
0D164140 PPC 0C183B48 RDFElementImpl::HandleDOMEvent(nsIPresContext&,
nsEvent*, nsIDOM
Event**, unsigned int, nsEventStatus&)+00480
0D164010 PPC 0BD8C09C nsEventListenerManager::HandleEvent(nsIPresContext&,
nsEvent*, n
sIDOMEvent**, unsigned int, nsEventStatus&)+00374
0D163EC0 PPC 0C3D79D0 nsJSEventListener::HandleEvent(nsIDOMEvent*)+001AC
0D163DB0 PPC 0C35A580 nsJSContext::CallFunction(void*, void*, unsigned
int, void*, int
*)+002B4
0D163CE0 PPC 0C2DCE74 JS_CallFunction+00044
0D163CA0 PPC 0C2FA92C js_InternalCall+000CC
0D163BF0 PPC 0C2FA680 js_Invoke+00980
0D163AF0 PPC 0C303588 js_Interpret+08318
0D163770 PPC 0C2FA680 js_Invoke+00980
0D163670 PPC 0C303588 js_Interpret+08318
0D1632F0 PPC 0C2FA61C js_Invoke+0091C
0D1631F0 PPC 0BB9A0A4 WrappedNative_CallMethod(JSContext*, JSObject*,
unsigned int, lo
ng*, long*)+00170
0D163170 PPC 0BB98144
nsXPCWrappedNativeClass::CallWrappedMethod(JSContext*, nsXPCWrap
pedNative*, const XPCNativeMemberDescriptor*, nsXPCWrappedNativeClass::CallMode,
unsigned int
, long*, long*)+00E48
0D162F30 PPC 0C4B5DD8 XPTC_InvokeByIndex+0002C
0D162EF0 PPC 0C4B5EE0 _XPTC_InvokeByIndex+000C8
0D162E44 PPC 0C129AF4 nsProfile::MigrateProfile(const char*, int)+00690
0D162BD4 PPC 0BA1BCDC nsPrefMigration::ProcessPrefs(int)+0027C
0D162B24 PPC 0C2A9830 nsWebShellWindow::ShowModal()+00018
0D162AE4 PPC 0C2A99AC nsWebShellWindow::ShowModalInternal()+00124
0D162A84 PPC 0C265140 nsAppShell::DispatchNativeEvent(int, void*)+00054
0D162A24 PPC 0C2657A0 nsMacMessagePump::DispatchEvent(int, EventRecord*)+
00188
0D1629D4 PPC 10F982E4 Repeater::DoRepeaters(const EventRecord&)+00034
0D162994 PPC 0C242354 nsMacNSPREventQueueHandler::RepeatAction(const
EventRecord&)+000
2C
0D162954 PPC 0C467BB8 nsEventQueueServiceImpl::ProcessEvents()+0002C
0D162914 PPC 0C462E00 nsHashtable::Enumerate(int (*)(nsHashKey*, void*,
void*), void*)
+0003C
0D1628D4 PPC 0C4F7F2C PL_HashTableEnumerateEntries+00060
0D162864 PPC 0C462640 _hashEnumerate(PLHashEntry*, int, void*)+00030
0D162824 PPC 0C467AFC EventDispatchingFunc(nsHashKey*, void*, void*)+00020
0D1627E4 PPC 0C466ABC EventQueueEntry::GetEventQueue()+0002C
Return addresses on the stack
Stack Addr Frame Addr ISA Caller
0D162B2C PPC 0BA1BCDC nsPrefMigration::ProcessPrefs(int)+
0027C
0D162AEC 0D162AE4 PPC 0C2A9830 nsWebShellWindow::ShowModal()+00018
0D162AC4 68K 0CCCAA82
0D162AA4 68K 0CCCAA82
0D162A8C 0D162A84 PPC 0C2A99AC nsWebShellWindow::ShowModalInternal()+
00124
0D162A4C 0D162A44 PPC 0C2545AC nsBaseWidget::AddRef()+0005C
0D162A2C 0D162A24 PPC 0C265140 nsAppShell::DispatchNativeEvent(int,
void*)+00054
0D1629DC 0D1629D4 PPC 0C2657A0 nsMacMessagePump::DispatchEvent(int,
EventRecord*)+
00188
0D1629D0 68K 0CCCAA82
0D1629B0 68K 0CCCAA82
0D1629A0 68K 0CCCAA82
0D16299C 0D162994 PPC 10F982E4 Repeater::DoRepeaters(const
EventRecord&)+00034
0D162994 68K 0D1629D2
0D16298C 68K 0CCCAA82
0D162978 68K 0CCCAA82
0D16295C 0D162954 PPC 0C242354
nsMacNSPREventQueueHandler::RepeatAction(const Even
tRecord&)+0002C
0D16294C 0D162944 PPC 10F991C0 TimerPeriodical::RepeatAction(const
EventRecord&)+0
0074
0D16291C 0D162914 PPC 0C467BB8
nsEventQueueServiceImpl::ProcessEvents()+0002C
0D1628F4 68K 0CCCAA82
0D1628EC 68K 0CCCAA82
0D1628DC 0D1628D4 PPC 0C462E00 nsHashtable::Enumerate(int (*
)(nsHashKey*, void*, v
oid*), void*)+0003C
0D1628CC 68K 0CCCAA82
0D162898 0D162894 68K 0020A526 'scod BFAF 0002'+01EB6
0D16286C 0D162864 PPC 0C4F7F2C PL_HashTableEnumerateEntries+00060
0D16282C 0D162824 PPC 0C462640 _hashEnumerate(PLHashEntry*, int, void*
)+00030
0D162824 0D162820 68K 0D162862
0D1627EC 0D1627E4 PPC 0C467AFC EventDispatchingFunc(nsHashKey*, void*,
void*)+0002
0
0D1627AC 0D1627A4 PPC 0C466ABC EventQueueEntry::GetEventQueue()+0002C
0D162796 68K 00000C5E
0D16276C 0D162764 PPC 0C46659C EventQueueStack::GetEventQueue()+0002C
Displaying memory from 0
00000000 FFC1 0000 FFC1 0000 00B9 807C 0020 86C8 *¡••*¡•••*Ä|• Ü»
00000010 0020 86CA 0020 86CC 00B9 811C 00B9 811C • Ü • ÜÕ*Å••*Å•
Closing log
Reporter | ||
Comment 2•25 years ago
|
||
actually, I'm not going to check that hack fix in.
I'll focus on debugging the real problem instead.
Comment 3•25 years ago
|
||
I've seen this crash too, when using Command-W to close a window. I think it's a
generic Mac widget bug. cc:ing people.
Reporter | ||
Comment 4•25 years ago
|
||
I'm glad it's not just me.
a six pac of beer for the mac guru who fixes this.
Reporter | ||
Comment 5•25 years ago
|
||
more info, it happens with one 4.x profile (meaning the automigration kicks in)
and with multiple 4.x profiles (meaning you get the profile manager and you have
to migrate.)
Reporter | ||
Comment 6•25 years ago
|
||
ok, I got an idea, and I'm debugging to see if I'm right.
we are iterating through all the events in the hash table.
could it be that in our hash table, we have a "close window / destroy window"
event (which, when handle causes the event queue to get destroyed) followed by
other events.
after the event queue is destroyed, we go process that next event, and boom.
just a guess, I'll continue to debug.
I love macsbug and codewarrior! bring it on!
Reporter | ||
Updated•25 years ago
|
Reporter | ||
Comment 7•25 years ago
|
||
I'm off to other mail news bugs.
marking this a blocker, as it's blocking me from fixing some mac migration /
profile manager bugs.
Comment 8•25 years ago
|
||
Danm was fixing a bug with the eventqueue being destroyed and losing events.
This was the openWebLocations bug. Maybe these bugs can share some knowledge.
Yes, a fix for bug 15856 will probably fix this one, too. It's probably the same problem, or similar, at least.
The current code throws away the stacked modal event queue as soon as the dialog is done with it, which
may be sooner than other users would want. I have reams of code in my tree to change the lifetime
of stacked event queues. You may want to leave this one alone until I check that in. In fact,
you probably want to assign this bug to me.
Updated•25 years ago
|
Assignee: dougt → danm
Comment 10•25 years ago
|
||
assigning to danm. if you need any help, just yell.
Whiteboard: [PDT+] → [PDT+] My machine stopped crashing, but I believe I've ID'd the problem.
Whiteboard: [PDT+] My machine stopped crashing, but I believe I've ID'd the problem. → [PDT+] fix coded, awaiting review
Reporter | ||
Comment 11•25 years ago
|
||
fixing dependency
Reporter | ||
Updated•25 years ago
|
Reporter | ||
Comment 12•25 years ago
|
||
fixing dependencies.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+] fix coded, awaiting review → [PDT+]
Assignee | ||
Comment 13•25 years ago
|
||
Actually, this had nothing to do with bug 15856. The problem was a combination of the Mac's habit of using
the nspr hashtable enumerator to process each thread's event queue, while in another thread, proxy code was
creating and destroying event queues in that hashtable. Hashtable enumerators can't handle that kind of abuse.
Fixed by inventing and using a different enumerator.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 14•25 years ago
|
||
builds 1999110808 and 1999110908
Comment 15•22 years ago
|
||
Moving all threading bugs to XPCOM. See bug 160356.
Component: Threading → XPCOM
You need to log in
before you can comment on or make changes to this bug.
Description
•