Closed Bug 61501 Opened 24 years ago Closed 24 years ago

App crash after using password dialog with -O3

Categories

(Core Graveyard :: RDF, defect, P3)

x86
Linux
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cls, Assigned: cls)

References

Details

(Keywords: crash)

Attachments

(2 files)

First, let me preface this by stating that I'm only seeing this with my gcc 2.95.2 -O3 builds. My gcc 2.95.2 -O2 & egcs 1.1.2 -O builds do not see this problem. The entire app crashes during the destruction of the password dialog that pops up when going to a webpage that requires authentication or logging into your imap account. I'm perfectly willing to accept that this is a bug in gcc 2.95.2 -O3 optimization but since it was working fine with a build from yesterday morning, I'd like to find out what triggered it. First noticed it in a pull from about 10pm last night. Here's the trace: #0 0x2b33cb21 in nsXULElement::nsIDOMEventReceiver virtual table () at ../../../../mozilla/rdf/content/src/nsXULElement.h:180 #1 0x2ab8d627 in nsCOMPtr_base::~nsCOMPtr_base () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/libxpcom.so #2 0x2b30e3fd in nsXULTemplateBuilder::IsDirectlyContainedBy () at ../../../../mozilla/rdf/content/src/nsXULElement.h:180 #3 0x2b30e804 in nsXULTemplateBuilder::RemoveMember () at ../../../../mozilla/rdf/content/src/nsXULElement.h:180 #4 0x2b30a95c in nsXULTemplateBuilder::Retract () at ../../../../mozilla/rdf/content/src/nsXULElement.h:180 #5 0x2b317594 in nsXULTemplateBuilder::OnUnassert () at ../../../../mozilla/rdf/content/src/nsXULElement.h:180 #6 0x2b2b6dae in CompositeDataSourceImpl::OnUnassert () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/components/librdf.so #7 0x2b2b8725 in InMemoryDataSource::Unassert () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/components/librdf.so #8 0x2b2bd754 in RDFContainerImpl::RemoveElement () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/components/librdf.so #9 0x2af3055b in nsWindowMediator::UnregisterWindow () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/components/libnsappshell.so #10 0x2af30416 in nsWindowMediator::UnregisterWindow () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/components/libnsappshell.so ---Type <return> to continue, or q <return> to quit--- #11 0x2af27fe6 in nsAppShellService::UnregisterTopLevelWindow () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/components/libnsappshell.so #12 0x2af21c06 in nsXULWindow::Destroy () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/components/libnsappshell.so #13 0x2af2bbae in nsWebShellWindow::Destroy () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/components/libnsappshell.so #14 0x2af1f117 in nsChromeTreeOwner::Destroy () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/components/libnsappshell.so #15 0x2ae6b8af in GlobalWindowImpl::Close () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/libjsdom.so #16 0x2ae76209 in GlobalWindowImpl::CloseWindow () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/libjsdom.so #17 0x2ae56c24 in nsJSContext::ScriptEvaluated () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/libjsdom.so #18 0x2ae55aea in nsJSContext::CallEventHandler () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/libjsdom.so #19 0x2ae971ab in nsJSEventListener::HandleEvent () from /usr/cls/moz/main/obj-opt-O3-gcc2952/dist/bin/libjsdom.so
cc'ing kandrot and thesteve, who may be interestedin stealing this bug.
Summary: App crash after using password dialog → App crash after using password dialog with -O3
Keywords: crash
Blocks: O2
With jst's help, I spent the last couple of hours trying to figure out exactly where and why -O3 builds fail when closing the dialog. The trouble has something to do with the do-loop in nsXULTemplateBuilder::IsDirectlyContainedBy(). If I comment out the first part of that loop or remove the generatedParent & tmplParent declarations outside of the loop, the error goes away. I've attached jst's patch which optimizes that loop a bit and fixes my -O3 problem..
Looks good to me (r=waterson, if you need it). Why don't you add a comment that you're doing the `tmp = foo' stuff to make -O3 work right on gcc so that nobody comes along later to ``clean it up''. :-)
brendan, can we get a sr=?
What waterson wrote: compiler workarounds need big ugly comments blaming the specific version and optimization level, so that some fine day, we can get rid of such ugly hackarounds for then-obsolete busted compilers. Add such comments and sr=brendan@mozilla.org. /be
Attached patch same patch with updated comment (deleted) — Splinter Review
Ship it, baby.
cls, you have r=waterson and sr=brendan, check it in!
Assignee: waterson → cls
Oops. Sorry, I checked this in a couple of days ago.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
tever is not RDF QA anymore
QA Contact: tever → nobody
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: