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.
->pav, the new owner of timers.
Assignee: asa → pavlov
i do not own timers. find a new owner.
Assignee: pavlov → 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?
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
I'll try the 78611 patch and see what happens.
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
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6
Created attachment 54377 [details] [diff] [review] patch to move the kungFuDeathGrip back one function
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).
yes, wrong bug.
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.6 → ---
David, are you still seeing this? It wfm w2k build 2001110103
Yes, works for me with a trunk debug build from this morning 11/1
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.