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
do other dialogs work or just the image dialog is broken? can you insert a table? can you spellcheck?
spell check works fine, as does H. line insert crashed in table insert. changed summary to reflect this discovery
Summary: Crash on image insert. → Crash on image or table insert dialogue open.
this is very probably not editor code, but we're on top of it (as soon as builds are finished.)
Any chance this could be related to the changes for bug 69468?
Do you have a windows talkback report on this crash?
dbaron, look above, Tracy added a talkback report URL...
hmmmm...talkback came up and I sent the report from windows for the crash, but I can't find it in the database
From the linux disassembly in the talkback report I'm guessing that this is a crash in nsAFlatString::GetReadableFragment because GetBufferHandle is returning null.
The above report is a Linux talkback report. Windows talkback reports have line numbers, but linux ones don't.
shiva helped me track it down...windows crash for table insert: http://cyclone/reports/SingleIncidentInfo.cfm?dynamicBBID=37130005
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...
Mine, all mine. Looks like the XPConnect null-string stuff caused this, investigating.
Assignee: syd → jst
Created attachment 54909 [details] [diff] [review] Fix nsAFlatString::GetReadableFragment() to cope with a null buffer handle
Comment on attachment 54909 [details] [diff] [review] Fix nsAFlatString::GetReadableFragment() to cope with a null buffer handle email@example.com Do we really want to assert?
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.
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.
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
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().
*** Bug 106528 has been marked as a duplicate of this bug. ***
tracy, does this work for you in today's 10/25 trunk builds ?
yes, worked fine cross plaform with this mornings pre 8 am builds. verified fixed
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.