nsTimer is getting an access violation when destructing

RESOLVED WORKSFORME

Status

SeaMonkey
General
--
critical
RESOLVED WORKSFORME
17 years ago
14 years ago

People

(Reporter: David Bradley, Assigned: Stuart Parmenter)

Tracking

({crash})

Trunk
x86
Windows 2000
crash

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 obsolete attachment)

(Reporter)

Description

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

Updated

17 years ago
Severity: normal → critical
Keywords: crash

Comment 1

17 years ago
->pav, the new owner of timers.
Assignee: asa → pavlov
(Assignee)

Comment 2

17 years ago
i do not own timers.  find a new owner.
Assignee: pavlov → asa

Comment 3

17 years ago
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?
(Assignee)

Comment 4

17 years ago
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.
Depends on: 78611
(Reporter)

Comment 5

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

Comment 6

17 years ago
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.
Assignee: asa → pavlov
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Keywords: patch
Target Milestone: --- → mozilla0.9.6
(Assignee)

Comment 7

17 years ago
Created attachment 54377 [details] [diff] [review]
patch to move the kungFuDeathGrip back one function
(Assignee)

Comment 8

17 years ago
since process_timers uses 'timer' after FireTimeout returns, we move the
kungFuDeathGrip from FireTimeout to process_timers.
As pavlov pointed out, that really belongs on bug 83163 (which took us both a
while to find, although we knew it existed).
(Assignee)

Updated

17 years ago
Attachment #54377 - Attachment is obsolete: true
(Assignee)

Comment 10

17 years ago
yes, wrong bug.
Status: ASSIGNED → NEW
Keywords: patch
Target Milestone: mozilla0.9.6 → ---

Comment 11

17 years ago
David, are you still seeing this?  It wfm w2k build 2001110103
(Reporter)

Comment 12

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

Comment 13

17 years ago
Marking WFM
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.