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)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: cls, Assigned: cls)
References
Details
(Keywords: crash)
Attachments
(2 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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
Comment 1•24 years ago
|
||
cc'ing kandrot and thesteve, who may be interestedin stealing this bug.
Updated•24 years ago
|
Summary: App crash after using password dialog → App crash after using password dialog with -O3
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..
Comment 4•24 years ago
|
||
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''. :-)
Comment 6•24 years ago
|
||
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
Comment 8•24 years ago
|
||
Ship it, baby.
Comment 9•24 years ago
|
||
cls, you have r=waterson and sr=brendan, check it in!
Assignee: waterson → cls
Assignee | ||
Comment 10•24 years ago
|
||
Oops. Sorry, I checked this in a couple of days ago.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•