106474 - Crash on image or table insert dialogue open.

Status: VERIFIED FIXED

(SeaMonkey :: Composer, defect)

Description

[Tracy Walker [:tracy]]

seen on commercial builds:

windows 2001-10-24-06-trunk
linux 2001-10-24-06-trunk

-open composer window
-click on the insert image icon or Insert | Image menu item

crash.

note: image open in the browser works fine.

talk back report here: 
http://cyclone/reports/SingleIncidentInfo.cfm?dynamicBBID=37121192

Comment 1

[sujay]

do other dialogs work or just the image dialog is broken?
can you insert a table?  can you spellcheck?

Comment 2

[Tracy Walker [:tracy]]

spell check works fine, as does H. line insert

crashed in table insert. 

changed summary to reflect this discovery

Comment 3

[Charles Manske]

this is very probably not editor code, but we're on top of it (as soon as builds
are finished.)

Comment 4

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Any chance this could be related to the changes for bug 69468?

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Do you have a windows talkback report on this crash?

Comment 6

[sujay]

dbaron, look above, Tracy added a talkback report URL...

Comment 7

[Tracy Walker [:tracy]]

hmmmm...talkback came up and I sent the report from windows for the crash, but I 
can't find it in the database

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

From the linux disassembly in the talkback report I'm guessing that this is a
crash in nsAFlatString::GetReadableFragment because GetBufferHandle is returning
null.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

The above report is a Linux talkback report.  Windows talkback reports have line
numbers, but linux ones don't.

Comment 10

[Tracy Walker [:tracy]]

shiva helped me track it down...windows crash for table insert:
http://cyclone/reports/SingleIncidentInfo.cfm?dynamicBBID=37130005

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: Windows talkback stack

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I suspect this may be related to jst's checkin yesterday, but testing a backout
to see if that's really the problem will take a little time...

Comment 13

[Johnny Stenback (:jst)]

Mine, all mine. Looks like the XPConnect null-string stuff caused this,
investigating.

Comment 14

[Johnny Stenback (:jst)]

Attachment: Fix nsAFlatString::GetReadableFragment() to cope with a null buffer handle

Comment 15

[kinmoz]

Comment on attachment 54909 [details] [diff] [review]
Fix nsAFlatString::GetReadableFragment() to cope with a null buffer handle

r=[e-mail]

Do we really want to assert?

Comment 16

[Scott Collins]

Comment on attachment 54909 [details] [diff] [review]
Fix nsAFlatString::GetReadableFragment() to cope with a null buffer handle

ugh.  sr=scc.  We'll have to figure out what to do about that assertion.  It should probably become a warning, now that we `handle' the problem.

Comment 17

[Johnny Stenback (:jst)]

Fix checked in, marking FIXED.

Scc, IMO we don't need a warning, we either ASSERT (i.e. revert my fix) and fix
the string code to never return a null buffer handle, or we don't warn at all
since returning a null buffer handle is ok. If you don't agree, re-open this bug
and set to normal in stead of blocker.

Comment 18

[Johnny Stenback (:jst)]

For the record, this particular bug was caused by my XPConnect null string
checkin last night, but the problem was a crash waiting to happen even before
that. Other string classes (nsXPIDLString, and probably other classes too) can
return null from GetBufferHandle().

Comment 19

[[e-mail] (gone - use [e-mail] instead)]

*** Bug 106528 has been marked as a duplicate of this bug. ***

Comment 20

[sujay]

tracy, does this work for you in today's 10/25 trunk builds ?

Comment 21

[Tracy Walker [:tracy]]

yes, worked fine cross plaform with this mornings pre 8 am builds.
verified fixed