87335 - nsTimer is getting an access violation when destructing

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[David Bradley]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.1+)
Gecko/20010612
BuildID:    From the trunk on 6/21 at 6pm

The following is the stack trace:
nsTimer::~nsTimer() line 122 + 24 bytes
nsTimer::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsTimer::Release(nsTimer * const 0x04501478) line 94 + 151 bytes
nsTimerManager::FireNextReadyTimer(nsTimerManager * const 0x00dbcd20, unsigned
int 0) line 117 + 12 bytes
nsAppShell::Run(nsAppShell * const 0x00cba708) line 118
nsAppShellService::Run(nsAppShellService * const 0x00cbb260) line 419
main1(int 1, char * * 0x00357518, nsISupports * 0x00000000) line 1161 + 32 bytes
main(int 1, char * * 0x00357518) line 1464 + 37 bytes
mainCRTStartup() line 338 + 17 bytes
KERNEL32! 77e87903()


Reproducible: Always
Steps to Reproduce:
1. Enter query critiera and hit submit
2. Press the Back button after the query has completed
3. Press the Forward button as soone as the query page appears
4. Repeat steps 2 and 3 several times till it fails (Usually takes three or 4 times)

Actual Results:  Access violation

Expected Results:  No access violation

This would appear to possibly be a race condition. My build is a debug build, so
you might not see this in a release build, or may be difficult to reproduce.
There's a ton of strict JS warning messages that fly by when the query page is
displayed.

I'm not going to make this a crasher, since you have to go out of your way to
make it crash, I'll leave that up to the QA or Owner.

Comment 1

[Asa Dotzler [:asa]]

->pav, the new owner of timers.

Comment 2

[Stuart Parmenter]

i do not own timers.  find a new owner.

Comment 3

[Asa Dotzler [:asa]]

David Bradley, unfortunately I'm not a developer so I won't be fixing this bug.
 I don't know who should get it. I tried Pav since he said he had a patch that
would fix this but apparently he doesn't want the bug on his plate. Any ideas?

Comment 4

[Stuart Parmenter]

the patch in bug 78611 will fix this.  its just a big patch, that needs to be 
made to work on the mac, and is low on my priority list.

Comment 5

[David Bradley]

I'll try the 78611 patch and see what happens.

Comment 6

[John Bandhauer]

Hold on Pav. You can't claim you don't own timer bugs and then point at a bug 
report with big 'ol patchs you wrote that hack the shit out of timers. You 
stepped in it, it's yours. If not you then who? You've been hacking there so at 
minimum you ought to be able to say who best knows the code.

I can reproduce this using dbradley's steps. The reason I care is that I've been 
seeing this in Purify builds of the current branch (that thing we want to 
ship soon) when running chofmann's browser buster. I'm suprised no one has 
identified this as a topcrash. I'll try to figure out which url in browser 
buster is hitting the crash.

There is *some* chance that this is triggered by a DOM timer problem that jst is 
aware of. For instance... bug 68488.

Comment 7

[Stuart Parmenter]

Attachment: patch to move the kungFuDeathGrip back one function

Comment 8

[Stuart Parmenter]

since process_timers uses 'timer' after FireTimeout returns, we move the
kungFuDeathGrip from FireTimeout to process_timers.

Comment 9

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

As pavlov pointed out, that really belongs on bug 83163 (which took us both a
while to find, although we knew it existed).

Comment 10

[Stuart Parmenter]

yes, wrong bug.

Comment 11

[Terri Preston]

David, are you still seeing this?  It wfm w2k build 2001110103

Comment 12

[David Bradley]

Yes, works for me with a trunk debug build from this morning 11/1

Comment 13

[Terri Preston]

Marking WFM