Crash on closing TB if compose window has been opened [@ nsVoidArray::RemoveElementsAt][@ nsTextServicesDocument::`scalar deleting destructor']

RESOLVED DUPLICATE of bug 357861

Status

Thunderbird
General
--
critical
RESOLVED DUPLICATE of bug 357861
11 years ago
7 years ago

People

(Reporter: Mike Cowperthwaite, Assigned: Scott MacGregor)

Tracking

({crash, regression})

Trunk
x86
All
crash, regression

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

11 years ago
TB 3a1-1011, Win2K.

Steps to reproduce:
Open TB
Open Compose window
Close Compose window
Close TB

Actual result:
crash:  Talkback TB24464029Y
(Assignee)

Comment 1

11 years ago
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]
(Assignee)

Comment 2

11 years ago
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.
(Reporter)

Comment 3

11 years ago
Whoops -- I should've said, this was with a plain-text compose window.

I haven't tested repeatedly for consistency, but I've seen the crash at least four times since yesterday.  The talkback was from the simplest test I ran to try to reproduce it.  Simply opening and closing the 3-pane didn't crash.

I have no extensions beyond a (disabled) DOM Inspector, JavaScript debugger, and Talkback.
(Assignee)

Comment 4

11 years ago
I see this too using plain text compose, that was the missing ingredient.
(Assignee)

Comment 5

11 years ago
my debug build from this morning won't crash, but the release build does.

Updated

11 years ago
Keywords: regression
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]

Comment 6

11 years ago
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.

Updated

11 years ago
Depends on: 358820
(Assignee)

Comment 7

11 years ago
*** Bug 358938 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 8

11 years ago
Note: I was experiencing the problem at the dupe even without closing TB.
(Assignee)

Comment 9

11 years ago
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. 
(Reporter)

Comment 10

11 years ago
(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?

Comment 11

11 years ago
I often see a similar crash when restarting to install updates. Last was today in Thunderbird/3.0a1 ID:2006110603: 
TB25602058X
TB25275044K
TB25038955Y
...
(Reporter)

Comment 12

11 years ago
(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']
(Reporter)

Comment 14

11 years ago
Bug 355064 had a check-in, but this bug still exists.  Comment 12 still pertains.
Depends on: 357861
No longer depends on: 358820

Comment 15

11 years ago
I can reproduce on 2007011203-trunk/Linux.

TB28307794Z
OS: Windows 2000 → All
Duplicate of this bug: 359537

Updated

11 years ago
Duplicate of this bug: 366984

Comment 18

11 years ago
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
-----$

Comment 19

11 years ago
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.
(Reporter)

Comment 20

11 years ago
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.

Comment 21

11 years ago
Thanks for the pointer, I somehow overlooked it. But why do we have this one then?
(Assignee)

Comment 22

11 years ago
I'm pretty sure this is a dupe.
Status: NEW → RESOLVED
Last Resolved: 11 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.