In 20060415 debug browser 1.8.0 and 1.8 builds I showed timeouts in js1_5/Array/regress-94257.js. I could not reproduce any hangs, but did see ASSERTION: Potential deadlock between Monitor@... and Lock@... in xpcom/threads/nsAutoLock.cpp line 302. This timeout behavior on these tests in new since at least 2006-04-10.
Bob, this is not a JS engine bug. That assertion may or may not be related to the hang, but if the hang is a deadlock, then it likely is. Can you get stacks from all the threads, using gdb or VS.NET or whatever's going, once the process is hung? Also, get into the debugger with XPCOM_DEBUG_BREAK=trap set in the environment, continue past whatever bogus assertions you have to, and when the test hits the Potential deadlock, find me on IRC. It should be easy to track down the offending code. Bouncing to XPCOM for now, but this will probably end up elsewhere. /be
-> default owner
Assignee: general → nobody
QA Contact: general → xpcom
What are the steps to run this test to reproduce this bug?
this is 1.8.0 and 1.8 only.
Version: Trunk → 1.8 Branch
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.