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

Status: RESOLVED DUPLICATE of bug 357861

(Thunderbird :: General, defect)

Description

[Mike Cowperthwaite]

TB 3a1-1011, Win2K.

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

Actual result:
crash:  Talkback TB24464029Y

Comment 1

[Scott MacGregor]

Here's the stack trace:


nsVoidArray::RemoveElementsAt  [mozilla/xpcom/build/nsVoidArray.cpp, line 591]
nsTextServicesDocument::`scalar deleting destructor'

Comment 2

[Scott MacGregor]

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.

Comment 3

[Mike Cowperthwaite]

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.

Comment 4

[Scott MacGregor]

I see this too using plain text compose, that was the missing ingredient.

Comment 5

[Scott MacGregor]

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

Comment 6

[William Price]

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.

Comment 7

[Scott MacGregor]

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

Comment 8

[Mike Cowperthwaite]

Note: I was experiencing the problem at the dupe even without closing TB.

Comment 9

[Scott MacGregor]

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. 

Comment 10

[Mike Cowperthwaite]

(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

[Alexey N. Solofnenko]

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

Comment 12

[Mike Cowperthwaite]

(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.

Comment 13

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Same happend for me. Is the spellchecker also included for SeaMonkey? So we should decide how to handle bug 357861 and bug 359537.

Comment 14

[Mike Cowperthwaite]

Bug 355064 had a check-in, but this bug still exists.  Comment 12 still pertains.

Comment 15

[Hideo Oshima]

I can reproduce on 2007011203-trunk/Linux.

TB28307794Z

Comment 18

[baffclan]

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

[Ere Maijala (slow)]

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.

Comment 20

[Mike Cowperthwaite]

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

[Ere Maijala (slow)]

Thanks for the pointer, I somehow overlooked it. But why do we have this one then?

Comment 22

[Scott MacGregor]

I'm pretty sure this is a dupe.