TB 3a1-1011, Win2K. Steps to reproduce: Open TB Open Compose window Close Compose window Close TB Actual result: crash: Talkback TB24464029Y
Here's the stack trace: nsVoidArray::RemoveElementsAt [mozilla/xpcom/build/nsVoidArray.cpp, line 591] nsTextServicesDocument::`scalar deleting destructor'
Summary: Crash on closing TB if compose window has been opened → Crash on closing TB if compose window has been opened [crash @ nsVoidArray::RemoveElementsAt]
I can't reproduce this using version 3 alpha 1 (20061009). Actually I just updated to version 3 alpha 1 (20061012) and that seems to work too. I'm using an html compose window so far. I'll keep poking at it.
I see this too using plain text compose, that was the missing ingredient.
my debug build from this morning won't crash, but the release build does.
Summary: Crash on closing TB if compose window has been opened [crash @ nsVoidArray::RemoveElementsAt] → Crash on closing TB if compose window has been opened [@ nsVoidArray::RemoveElementsAt]
I exhibit the same behavior; it started weeks ago and I've been putting up with it until now. Talkback incident TB25127727K if it helps any. Trunk 20061024 nightly on WinXP.
*** Bug 358938 has been marked as a duplicate of this bug. ***
Note: I was experiencing the problem at the dupe even without closing TB.
Also, see Bug 357861. According to that bug this crash is fixed by the patch in Bug 357861 but I haven't been able to understand why yet.
(In reply to comment #9) > According to [bug 357861] this crash is fixed by the patch in > Bug 357861 but I haven't been able to understand why yet. ~~~~~~~~~~ You meant bug 355064 in that second sentence, I think. Has that patch been checked in?
I often see a similar crash when restarting to install updates. Last was today in Thunderbird/3.0a1 ID:2006110603: TB25602058X TB25275044K TB25038955Y ...
(In reply to comment #9) > this crash is fixed by the patch in > [bug 355064] but I haven't been able to understand why yet. I can verify that turning off inline spell-checking results in no more crashes of this type. But nothing's happening at that bug.
Same happend for me. Is the spellchecker also included for SeaMonkey? So we should decide how to handle bug 357861 and bug 359537.
Summary: Crash on closing TB if compose window has been opened [@ nsVoidArray::RemoveElementsAt] → Crash on closing TB if compose window has been opened [@ nsVoidArray::RemoveElementsAt][@ nsTextServicesDocument::`scalar deleting destructor']
I can reproduce on 2007011203-trunk/Linux. TB28307794Z
OS: Windows 2000 → All
I can reproduce on SeaMonkey/2007011308-trink/WinXP, talkback ID : TB28470549Y -----^ Incident ID: 28470549 Stack Signature 0x01a062df 07a320b4 Product ID MozillaTrunk Build ID 2007011308 Trigger Time 2007-01-18 03:32:28.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module URL visited User Comments Since Last Crash 561 sec Total Uptime 561 sec Trigger Reason Access violation Source File, Line No. N/A Stack Trace 0x01a062df nsTextServicesDocument::`scalar deleting destructor' 0x02f92d88 0xf64fe908 -----$
I've been trying to trace this but can't reproduce reliably (crashes only intermittently). When a crash has occurred, nsVoidArray::mCount has been largish negative number causing IndexOf to crash when editor calls RemoveEditActionListener. Once I've also got a "damage after normal block" message from VC++ debug library indicating that out of bounds memory has been trashed.
Ere, have you been following bug 357861? There's a patch there waiting review which may address this as well. Scott mentions that he couldn't reproduce the crash within the debugger.
Thanks for the pointer, I somehow overlooked it. But why do we have this one then?
I'm pretty sure this is a dupe.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 357861
Crash Signature: [@ nsVoidArray::RemoveElementsAt] [@ nsTextServicesDocument::`scalar deleting destructor']
You need to log in before you can comment on or make changes to this bug.