Crash when initializing Midas (setting designMode and others)

RESOLVED FIXED

Status

()

Core
Editor
--
critical
RESOLVED FIXED
15 years ago
13 years ago

People

(Reporter: Ere Maijala (slow), Assigned: Ere Maijala (slow))

Tracking

({crash})

Trunk
x86
Windows XP
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(6 attachments)

(Assignee)

Description

15 years ago
I've experienced a crash with Midas in an intranet application. It works usually
fine, but there is one specific page which causes it to crash. I took the
contents of that page and minimized it to a crashing test case, which I will
attach to this bug. Running trunk build 2003070107 on WinXP, also happens with
20030714.
(Assignee)

Comment 1

15 years ago
Created attachment 127812 [details]
Test case

A test case simplified from a real life crash case.
Created attachment 127813 [details]
win2k stack

*** This bug has been marked as a duplicate of 171949 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 4

15 years ago
Created attachment 127826 [details]
My stack

My stack is completely different.
(Assignee)

Comment 5

15 years ago
Reopening. There was yet another place it crashed in talkback 21908653q.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---

Comment 6

15 years ago
Created attachment 127985 [details]
Purify stack to the error, free, and allocation locations

I'm attaching the purify data, it shows where the object was created and
destroyed that the QI is failing on.

From what I can tell is that an event is fired, and the command controller
still has a reference to the editor which was destroyed when leaving
nsEditingSession::TearDownEditorOnWindow. I suspect maybe there's some kind of
contract between the nsEditingSession and the command controller built, that it
keeps things alive as long as needed. I think the
nsEditingSession::TearDownEditorOnWindow needs to clean up the command
controller before it exits, since I think all references to the object in
question will be gone.

Comment 7

15 years ago
-->me
Assignee: jfrancis → brade
Status: REOPENED → NEW

Comment 8

14 years ago
Duplicate of bug 211348?
(Assignee)

Comment 9

14 years ago
Created attachment 140075 [details] [diff] [review]
Patch v1

Need to null out the weak refs to the editor on the controllers before it's
destroyed (nulled out on the docshell). Otherwise there is a small timeframe
when someone can try to use the destroyed editor. This fixes the crash my stack
and the Purify stack show.
(Assignee)

Updated

14 years ago
Assignee: brade → ere
Status: NEW → ASSIGNED
(Assignee)

Updated

14 years ago
Attachment #140075 - Flags: review?(mozeditor)
(Assignee)

Updated

14 years ago
Attachment #140075 - Flags: superreview?(bz-vacation)
It'll take me some time (two weeks or more, possibly) to get to this review --
I'm somewhat behind on reviews at the moment.

For future reference, using the -p flag to diff makes patches like this far more
readable...
(Assignee)

Comment 11

14 years ago
Created attachment 140088 [details] [diff] [review]
Patch v1 with some more context

Oops, I did it again. This is the same with some more context.

Comment 12

14 years ago
Comment on attachment 140088 [details] [diff] [review]
Patch v1 with some more context

Are there any leaks?  Is "PreDestroy" being called?  Maybe the ordering thing I
was worried about is the selection and doc state listener; I'm not sure
(sorry).
(Assignee)

Comment 13

14 years ago
No problem, I'll test it.
(Assignee)

Comment 14

14 years ago
PreDestroy is being called just fine. As far as I can see the patch causes no
problems or changes in behavior.
(Assignee)

Comment 15

14 years ago
Comment on attachment 140075 [details] [diff] [review]
Patch v1

Seeking r from Brade who seems to know this stuff well :)
Attachment #140075 - Flags: superreview?(bz-vacation)
Attachment #140075 - Flags: review?(mozeditor)
Attachment #140075 - Flags: review?(brade)

Comment 16

14 years ago
looks ok to me.
(Assignee)

Comment 17

14 years ago
Comment on attachment 140075 [details] [diff] [review]
Patch v1

That would be an r+?
Attachment #140075 - Flags: superreview?(dbaron)
Attachment #140075 - Flags: superreview?(dbaron) → superreview+

Comment 18

14 years ago
Comment on attachment 140075 [details] [diff] [review]
Patch v1

r=brade (assuming mail compose and composer have both been tested and no
regressions found)
Attachment #140075 - Flags: review?(brade) → review+
(Assignee)

Comment 19

14 years ago
Comment on attachment 140075 [details] [diff] [review]
Patch v1

Yes, I wasn't able to find any problems in mail compose or composer. Requesting
approval for 1.7a.
Attachment #140075 - Flags: approval1.7a?

Comment 20

14 years ago
Comment on attachment 140075 [details] [diff] [review]
Patch v1

a=chofmann for 1.7a
(Assignee)

Comment 21

14 years ago
Fix checked in.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago14 years ago
Resolution: --- → FIXED

Updated

14 years ago
Attachment #140075 - Flags: approval1.7a? → approval1.7a+

Comment 22

13 years ago
i still see this problem in 1.7.3 on win2k.

Comment 23

13 years ago
so file a new bug with a stack trace.
You need to log in before you can comment on or make changes to this bug.