Closed Bug 4883 Opened 26 years ago Closed 26 years ago

[PP] Apprunner frequently crashing in CalcOffset (upon closing Window)

Categories

(Core :: Layout: Form Controls, defect, P1)

Product:
Core
Component:
Layout: Form Controls
Platform:
PowerPC
Mac System 8.5
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: elig, Assigned: mikepinkerton)

Details

(Whiteboard: QA BLOCKER)

* TITLE/SUMMARY Apprunner frequently crashing in CalcOffset * STEPS TO REPRODUCE 0) Launch Apprunner 1) Do something. (Normally consisting of clicking in the URL text field, or closing an Apprunner window.) * RESULT - What happened Irreproducibly, Apprunner crashes. Simon says that Pinkerton should get this. * REGRESSION - Occurs On Mac OS Apprunner (4.9.99 AM optimized build) - Haven't Seen On Win32 Apprunner (4.9.99 AM optimized build [NT 4, Service Pack 3]) Linux Apprunner (4.9.99 AM optimized build) * STACK CRAWL PowerPC access exception at 0B0A3680 Calling chain using A6/R1 links Back chain ISA Caller 00000000 PPC 0B72FBF0 03AFF540 PPC 0B72EBA8 main+0053C 03AFF450 PPC 0B4F66A0 nsAppShellService::Run()+00018 03AFF410 PPC 0B096B34 nsAppShell::Run()+00038 03AFF390 PPC 0B097480 nsMacMessagePump::DoMessagePump()+0003C 03AFF340 PPC 0B0975EC nsMacMessagePump::DispatchEvent(int, EventRecord*)+ 00048 03AFF2F0 PPC 0B097C74 nsMacMessagePump::DoKey(EventRecord&)+00088 03AFF2B0 PPC 0B097F1C nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort *)+00044 03AFF260 PPC 0B092490 nsMacMessageSink::DispatchOSEvent(EventRecord&, GrafPort*)+00038 03AFF220 PPC 0B08E5D8 nsMacWindow::HandleOSEvent(EventRecord&)+00020 03AFF1C0 PPC 0B08E8DC nsMacEventHandler::HandleOSEvent(EventRecord&)+0003C 03AFF180 PPC 0B08F168 nsMacEventHandler::HandleKeyEvent(EventRecord&)+ 00160 03AFF0E0 PPC 0B07DF18 nsTextWidget::DispatchWindowEvent(nsGUIEvent&)+00090 03AFEFD0 PPC 0B079AB0 nsWindow::DispatchWindowEvent(nsGUIEvent&)+00018 03AFEF90 PPC 0B0799DC nsWindow::DispatchEvent(nsGUIEvent*, nsEventStatus& )+00090 03AFEF40 PPC 0AF73C0C HandleEvent(nsGUIEvent*)+00058 03AFEEF0 PPC 0AF71550 nsViewManager::DispatchEvent(nsGUIEvent*, nsEventStatus&)+005D0 03AFEDB0 PPC 0AF75694 nsView::HandleEvent(nsGUIEvent*, unsigned int, nsEventStatus&)+0 0104 03AFED30 PPC 0AF6A8F4 nsScrollingView::HandleEvent(nsGUIEvent*, unsigned int, nsEventS tatus&)+000C4 03AFECE0 PPC 0AF75694 nsView::HandleEvent(nsGUIEvent*, unsigned int, nsEventStatus&)+0 0104 03AFEC60 PPC 0AF75694 nsView::HandleEvent(nsGUIEvent*, unsigned int, nsEventStatus&)+0 0104 03AFEBE0 PPC 0AF75694 nsView::HandleEvent(nsGUIEvent*, unsigned int, nsEventStatus&)+0 0104 03AFEB60 PPC 0AF75724 nsView::HandleEvent(nsGUIEvent*, unsigned int, nsEventStatus&)+0 0194 03AFEAE0 PPC 0B1770F0 PresShell::HandleEvent(nsIView*, nsGUIEvent*, nsEventStatus&)+00 1A8 03AFEA70 PPC 0B263018 nsHTMLInputElement::HandleDOMEvent(nsIPresContext&, nsEvent*, ns IDOMEvent**, unsigned int, nsEventStatus&)+00010 03AFEA30 PPC 0B342428 nsGenericElement::HandleDOMEvent(nsIPresContext&, nsEvent*, nsID OMEvent**, unsigned int, nsEventStatus&)+000DC 03AFE9D0 PPC 0B1F0E00 nsEventListenerManager::HandleEvent(nsIPresContext&, nsEvent*, n sIDOMEvent**, unsigned int, nsEventStatus&)+00780 03AFE8E0 PPC 0B4C0FDC nsJSEventListener::HandleEvent(nsIDOMEvent*)+0015C 03AFE850 PPC 0B5810E0 JS_CallFunctionValue+00014 03AFE810 PPC 0B599528 js_CallFunctionValue+000B8 03AFE760 PPC 0B599328 js_Invoke+0057C 03AFE680 PPC 0B59F1B4 js_Interpret+055F0 03AFE460 PPC 0B599328 js_Invoke+0057C 03AFE380 PPC 0B59F1B4 js_Interpret+055F0 03AFE160 PPC 0B5992D0 js_Invoke+00524 03AFE080 PPC 0B030A60 BrowserAppCoreLoadUrl(JSContext*, JSObject*, unsigned int, long* , long*)+000AC 03AFDFD0 PPC 0B02A8E0 nsBrowserAppCore::LoadUrl(const nsString&)+00078 03AFDF80 PPC 0B01A7B0 nsWebShell::LoadURL(const unsigned short*, nsIPostData*, int, ns URLReloadType, unsigned int)+00060 03AFDF30 PPC 0B01BA58 nsWebShell::LoadURL(const unsigned short*, const char*, nsIPostD ata*, int, nsURLReloadType, unsigned int)+00398 03AFDDE0 PPC 0B01AAF8 nsWebShell::DoLoadURL(const nsString&, const char*, nsIPostData* , nsURLReloadType, unsigned int)+002DC 03AFDD00 PPC 0B0108A4 nsDocLoaderImpl::LoadDocument(const nsString&, const char*, nsIC ontentViewerContainer*, nsIPostData*, nsISupports*, nsIStreamObserver*, nsURLReloadType, unsi gned int)+001A8 03AFDC90 PPC 0B012680 nsDocumentBindInfo::Bind(const nsString&, nsIPostData*, nsIStrea mListener*)+00124 03AFDC40 PPC 0B01149C nsDocLoaderImpl::FireOnStartDocumentLoad(nsIURL*, const char*)+0 0050 03AFDBF0 PPC 0B01D618 nsWebShell::OnStartDocumentLoad(nsIURL*, const char* )+00128 03AFDB60 PPC 0B02B5B8 nsBrowserAppCore::OnStartDocumentLoad(nsIURL*, const char*)+0003 C 03AFDB10 PPC 0B02B188 setAttribute(nsIWebShell*, const char*, const char*, const nsStr ing&)+00270 03AFDA30 PPC 0B43DDA4 RDFElementImpl::SetAttribute(const nsString&, const nsString&)+0 0058 03AFD9E0 PPC 0B438480 XULDocumentImpl::OnSetAttribute(nsIDOMElement*, const nsString&, const nsString&)+0007C 03AFD980 PPC 0B42648C RDFXULBuilderImpl::OnSetAttribute(nsIDOMElement*, const nsString &, const nsString&)+0068C 03AFD7B0 PPC 0B41B9D4 CompositeDataSourceImpl::Assert(nsIRDFResource*, nsIRDFResource* , nsIRDFNode*, int)+00058 03AFD750 PPC 0B4687B0 LocalStoreImpl::Assert(nsIRDFResource*, nsIRDFResource*, nsIRDFN ode*, int)+00018 03AFD710 PPC 0B41DFE4 RDFXMLDataSourceImpl::Assert(nsIRDFResource*, nsIRDFResource*, n sIRDFNode*, int)+00044 03AFD6D0 PPC 0B40C020 InMemoryDataSource::Assert(nsIRDFResource*, nsIRDFResource*, nsI RDFNode*, int)+0006C 03AFD670 PPC 0B41C8AC CompositeDataSourceImpl::OnAssert(nsIRDFResource*, nsIRDFResourc e*, nsIRDFNode*)+0005C 03AFD610 PPC 0B4247D0 RDFXULBuilderImpl::OnAssert(nsIRDFResource*, nsIRDFResource*, ns IRDFNode*)+00360 03AFD500 PPC 0B429110 RDFXULBuilderImpl::AddAttribute(nsIContent*, nsIRDFResource*, ns IRDFNode*)+00260 03AFD3F0 PPC 0B4407E4 RDFElementImpl::SetAttribute(int, nsIAtom*, const nsString&, int )+005D0 03AFD310 PPC 0B4423E4 RDFElementImpl::ExecuteOnChangeHandler(nsIDOMElement*, const nsS tring&)+001F0 03AFD140 PPC 0B442688 RDFElementImpl::ExecuteJSCode(nsIDOMElement*)+00190 03AFD060 PPC 0B441810 RDFElementImpl::HandleDOMEvent(nsIPresContext&, nsEvent*, nsIDOM Event**, unsigned int, nsEventStatus&)+00218 03AFCFC0 PPC 0B1F117C nsEventListenerManager::HandleEvent(nsIPresContext&, nsEvent*, n sIDOMEvent**, unsigned int, nsEventStatus&)+00AFC 03AFCED0 PPC 0B4C0FDC nsJSEventListener::HandleEvent(nsIDOMEvent*)+0015C 03AFCE40 PPC 0B5810E0 JS_CallFunctionValue+00014 03AFCE00 PPC 0B599528 js_CallFunctionValue+000B8 03AFCD50 PPC 0B599328 js_Invoke+0057C 03AFCC70 PPC 0B59F1B4 js_Interpret+055F0 03AFCA50 PPC 0B599328 js_Invoke+0057C 03AFC970 PPC 0B59F1B4 js_Interpret+055F0 03AFC750 PPC 0B5992D0 js_Invoke+00524 03AFC670 PPC 0B483364 ElementSetAttribute(JSContext*, JSObject*, unsigned int, long*, long*)+000C0 03AFC560 PPC 0B43DDA4 RDFElementImpl::SetAttribute(const nsString&, const nsString&)+0 0058 03AFC510 PPC 0B438480 XULDocumentImpl::OnSetAttribute(nsIDOMElement*, const nsString&, const nsString&)+0007C 03AFC4B0 PPC 0B42635C RDFXULBuilderImpl::OnSetAttribute(nsIDOMElement*, const nsString &, const nsString&)+0055C 03AFC2E0 PPC 0B41BB1C CompositeDataSourceImpl::Unassert(nsIRDFResource*, nsIRDFResourc e*, nsIRDFNode*)+00098 03AFC280 PPC 0B468720 LocalStoreImpl::Unassert(nsIRDFResource*, nsIRDFResource*, nsIRD FNode*)+00018 03AFC240 PPC 0B41E0C4 RDFXMLDataSourceImpl::Unassert(nsIRDFResource*, nsIRDFResource*, nsIRDFNode*)+00044 03AFC200 PPC 0B40C38C InMemoryDataSource::Unassert(nsIRDFResource*, nsIRDFResource*, n sIRDFNode*)+0006C 03AFC1A0 PPC 0B41C99C CompositeDataSourceImpl::OnUnassert(nsIRDFResource*, nsIRDFResou rce*, nsIRDFNode*)+0005C 03AFC140 PPC 0B424CE4 RDFXULBuilderImpl::OnUnassert(nsIRDFResource*, nsIRDFResource*, nsIRDFNode*)+00360 03AFC030 PPC 0B429304 RDFXULBuilderImpl::RemoveAttribute(nsIContent*, nsIRDFResource*, nsIRDFNode*)+000F0 03AFBFB0 PPC 0B440EEC RDFElementImpl::UnsetAttribute(int, nsIAtom*, int)+ 00238 03AFBEE0 PPC 0B43DE78 RDFElementImpl::RemoveAttribute(const nsString&)+ 00050 03AFBE90 PPC 0B4385C0 XULDocumentImpl::OnRemoveAttribute(nsIDOMElement*, const nsStrin g&)+00074 03AFBE30 PPC 0B426A00 RDFXULBuilderImpl::OnRemoveAttribute(nsIDOMElement*, const nsStr ing&)+003A8 03AFBCC0 PPC 0B41BB1C CompositeDataSourceImpl::Unassert(nsIRDFResource*, nsIRDFResourc e*, nsIRDFNode*)+00098 03AFBC60 PPC 0B468720 LocalStoreImpl::Unassert(nsIRDFResource*, nsIRDFResource*, nsIRD FNode*)+00018 03AFBC20 PPC 0B41E0C4 RDFXMLDataSourceImpl::Unassert(nsIRDFResource*, nsIRDFResource*, nsIRDFNode*)+00044 03AFBBE0 PPC 0B40C38C InMemoryDataSource::Unassert(nsIRDFResource*, nsIRDFResource*, n sIRDFNode*)+0006C 03AFBB80 PPC 0B41C99C CompositeDataSourceImpl::OnUnassert(nsIRDFResource*, nsIRDFResou rce*, nsIRDFNode*)+0005C 03AFBB20 PPC 0B424CE4 RDFXULBuilderImpl::OnUnassert(nsIRDFResource*, nsIRDFResource*, nsIRDFNode*)+00360 03AFBA10 PPC 0B429304 RDFXULBuilderImpl::RemoveAttribute(nsIContent*, nsIRDFResource*, nsIRDFNode*)+000F0 03AFB990 PPC 0B440F60 RDFElementImpl::UnsetAttribute(int, nsIAtom*, int)+ 002AC 03AFB8C0 PPC 0B4341F4 XULDocumentImpl::AttributeChanged(nsIContent*, nsIAtom*, int)+00 054 03AFB860 PPC 0B175EBC PresShell::AttributeChanged(nsIDocument*, nsIContent*, nsIAtom*, int)+00068 03AFB810 PPC 0B173224 PresShell::ExitReflowLock()+0002C 03AFB7D0 PPC 0B174CC4 PresShell::ProcessReflowCommands()+00070 03AFB750 PPC 0B175038 PresShell::CreateRenderingContext(nsIFrame*, nsIRenderingContext **)+00140 03AFB6C0 PPC 0B14B9B0 DeviceContextImpl::CreateRenderingContext(nsIView*, nsIRendering Context*&)+0006C 03AFB660 PPC 0B14BBA0 DeviceContextImpl::InitRenderingContext(nsIRenderingContext*, ns IWidget*)+00020 03AFB620 PPC 0B147564 nsRenderingContextMac::Init(nsIDeviceContext*, nsIWidget*)+0009C 03AFB550 PPC 0B14F004 nsDrawingSurfaceMac::Init(nsIWidget*)+0003C 03AFB510 PPC 0B146C94 GraphicState::Init(nsIWidget*)+0002C 03AFB4D0 PPC 0B0783BC nsWindow::GetNativeData(unsigned int)+0006C 03AFB470 PPC 0B07A40C nsWindow::LocalToWindowCoordinate(nsPoint&)+00018 03AFB430 PPC 0B07A378 nsWindow::ConvertToDeviceCoordinates(int&, int&)+ 00028 03AFB3E0 PPC 0B079F84 nsWindow::CalcOffset(int&, int&)+00094 Closing log
Assignee: karnaze → pinkerton
QA Contact: 4078 → 1698
Assignee: pinkerton → trudelle
why is this assigned to me? assigning to my manager.
cc'ing sfraser. Simon, why did you think Pink should get this one?
I've seen this fairly frequently in the debugger, and seem to recall that some null pointer is being accessed in nsWindow, so I think it's widget-related.
Assignee: trudelle → hyatt
I can't reproduce this, and I still don't see why it would be Pink's. Looks like some XUL content stuff on the stack, maybe Hyatt has some insight. reassigning to him as p4 for m5. Eli, it would be much better if you could find a reproducible case for this.
Summary: Apprunner frequently crashing in CalcOffset → Apprunner frequently crashing in CalcOffset (upon closing Window)
Franz was out, so I sent Hans over to trudelle's cubicle to reproduce this. (Needless to say, he was pumped up.) Anyway, the reproduction steps are vaguely like: #0. Launch Apprunner #1. Open a second browser window #2. Close the first browser window (Bonus points if you move things around while the computer is trying to work, and be sure to do step #2 while it's trying to do step #1.)
[Also, please note that I still can't reproduce this on Win32, and that the build I reproduced it on with the aforementioned steps was the 4.12.99 AM Mac OS build.]
Priority: P3 → P2
Target Milestone: M5
setting p2 for m5, cc'ing saari&pierre in case this is a Mac GFX thing
I have a suspicion that this is caused by timers firing after the window has gone away, which would be another side-effect of the massive webshell leakage (bug 4127). I've seen the progress StripTimer on the stack sometimes.
Status: NEW → ASSIGNED
elig, Mac only [PP] bug?
Summary: Apprunner frequently crashing in CalcOffset (upon closing Window) → [PP] Apprunner frequently crashing in CalcOffset (upon closing Window)
Mac only.
Assignee: hyatt → pinkerton
Status: ASSIGNED → NEW
Priority: P2 → P1
reassigning to pinkerton as p1 for m5
There is an inconsistency in the bug report. At the top of the stack is "nsMacMessagePump::DoKey" which shows that it crashed consecutively to a keyEvent but nowhere in the description is a keyEvent mentioned. Following are two very easy ways to reproduce a similar crash, which may or may not be identical to the one described above, pending further explanations from the reporter: - launch AppRunner (not Viewer) - open a second window - click the URL field of that second window - click the closeBox ==> crash - launch Viewer (not AppRunner) - click the URL field - click the closeBox or type cmd-W ==> crash Thanks for taking care of it, Pink. Are you taking other Widget bugs too?
Damn. Pierre discovered my secret. I actually just use a Perl script that generates random stack crawls, and pastes them into my bug reports. I'm now busily adapting it to generate random bug reports for me, too. ;) --- I don't understand what the inconsistency is (or, actually, even what the question is), so perhaps you can help me understand. The stack crawl provided was clearly provided when I didn't know how to reproduce the bug, so I probably pressed a key in the process of making it crash, among lots of other things. The reproduction steps that I subsequently at trudelle's request provided did not contain a keystroke. It looks like the same crash to me.
Status: NEW → ASSIGNED
accepting bug
it looks to me like the timer that blinks the cursor is firing after the window has been closed. Where are these timers set up and cleared? anyone know?
for the viewer case, two text widgets (url bar and status area) are being created. only one of them (the status area) ever gets deleted. So the dstr of the url bar text widget is never called, so it never gets the notice to stop repeating, hence the crash after the widget goes away. I think this is totally in viewer code. Anyone know why the url bar isn't being deleted? I'll look into why it's crashing in apprunner next.
The caret blink timer firing after the window has been closed is long-running issues with editor and mail compose windows, and a side-effect of the massive memory leak bug. As I understand it, this bug occurs when closing browser windows, for which there should be no blinking caret.
well, there is a blinking caret in the url bar. that's what is causing the crashes i see and how i was told to dup this bug. The url bar not being deleted in viewer is XP (happens on linux too). Only the status bar text widget ever gets deleted. This is not really my area of responsibility.
Ah. The caret in the URL bar is drawn by TextEdit, and draws on calls to IdleControls in nsTextWidget::RepeatAction(), which is called as an Idler. This has nothing to do with the ender caret.
I just traced through apprunner and the text widget isn't getting deleted when the main window is closed. This is on both mac and linux. That's why the repeater crashes when the window is not there (because the url bar is still trying to idle, but no window, so it goes boom when it tries to setup the drawing environment to flash the caret). This smells more and more like the web shell leaking bug that scc has (or will have very shortly). This crash is Mac only, but the symptom is XP. I'll hold onto this for a while longer and talk to scc about it. cc'ing him on this bug as well.
ok, i don't know what happened, but now the bugreport is back to singlespaced, even though i got a diff that was HUGE and looked like it deleted everything.... oh well. all looks well.
In viewer, at least, the toplevel widget is being leaked (mWindow member in nsBrowserWindow) so every single widget under it never gets disposed. Filed a new bug for this, #5483. Once that gets cleared up, this will get cleared up.
Whiteboard: QA BLOCKER
Adding to QA Blocker radar.
Assignee: pinkerton → pierre
Status: ASSIGNED → NEW
I've spent about 3 hours tracing this down and I've discovered two problems. One I have a fix for, the other I figured I'd let pierre handle because he knows the code much much better. The first problem (the one I have a fix for) is that in nsBrowserWindow::CreateToolbar() we QI the text widget twice (to the same interface, mind you) and only release it once. That is a definate memory leak and will cause the text widget to never be deleted properly whatever we do. That one is XP. I'll checkin a fix as soon as I get permission. The second problem for which I have to real solution is the following: in nsBrowserWindow::Close() we release the mWindow member. At the time (because the event system is still holding two refs to it), the window isn't deleted. However, later in the quit cycle, the event system releases its refs and the top level widget is deleted (calling nsMacWindow::~nsMacWindow). For some reason, Destroy() is never getting called on this object so the widget never releases it's children list (stored in mChildren). This causes the text widget (and all the other widgets, mind you) to still have a dangling reference. I noticed that Destroy() is commented out in nsWindow::~nsWindow on MacOS. I don't know why. It seems to do the right thing on windows, but the delete sequence is different there. This is why I'm reassigning to pierre, because he understands how all this stuff fits together at object destruction time. We're so close!
Ok, i just tested this to see if it still crashe in viewer and it doesn't. The destructors are being correctly called. I swear before I wrote that last comment I checked and the dstr's weren't being called at all. I'll test it in apprunner and see what happens there, but it looks like everything is good in the world.
Assignee: pierre → pinkerton
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
Ok, the dstr is not being called in apprunner, so we are certainly leaking the widgets there. The actual crasher in viewer is fixed, so I'll close this one out and keep working on 5483.
marking fixed.
I'm still seeing crashes in CalcOffset using the 4.29.99 build, but will defer until today's build for a full verification.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
After my marathon leak correction session with scc, we identifed the real reason for this crash (which really wasn't fixed). Once we finish with the webshell leak, I'll get back to this one. Reopening so I dont' forget.
Status: REOPENED → ASSIGNED
reolution cleared, marking assigned.
<thanks!>
Status: ASSIGNED → RESOLVED
Closed: 26 years ago → 26 years ago
Resolution: --- → FIXED
Added Destroy() method to do the same as the Repeater dtor would do but it wasn't getting called because the timer still held a ref to the widget. Appr chofmann. Marking as fixed.
Status: RESOLVED → VERIFIED
Using the 4.30.99 PM Mac OS build, I can't reproduce this bug anymore using the scenarios described by Pierre, or using the one I described. Thus, verified fixed.
Moving all Widget Set bugs, past and present, to new HTML Form Controls component per request from karnaze. Widget Set component will be retired shortly.
You need to log in before you can comment on or make changes to this bug.