STEPS TO REPRODUCE 1. Load Mozilla. 2. Go to a web page or reload your homepage. ACTUAL RESULTS Crash. This has been seen on both Linux and Windows tip builds. Mail works fine, as does the sidebar. It seems to only be the second page load in the main content area that triggers the crash. tor says it may have something to do with forms.
Keywords: crash, regression, smoketest
I am not seeing this in this morning's Linux build (2002021606) ... so we have a 5-6 hour window whether this could have happened. tor: that was 13:03PM what timezone? This stack is weird, as bz has pointed out on IRC. It dies in .get(), as though the nsCOMPtr<> itself is sitting in invalid memory.
2/17 4:51 pacific pull is working fine, fwiw.
11:30 Pacific pull is working fine too...
OK, something is weird. I tried a 19:35 pull in which I was _definitely_ seeing this crash before.... it is no longer there.
I _am_ however seeing lots of crashes in PR_Lock: (gdb) frame 1 #1 0x40339c5b in PR_Lock (lock=0x1) at ptsynch.c:183 183 rv = pthread_mutex_lock(&lock->mutex); (gdb) p lock $1 = (PRLock *) 0x1 (gdb) p &lock $2 = (PRLock **) 0xbdbff948 (gdb) p &lock->mutex $3 = (pthread_mutex_t *) 0x1 and (gdb) frame 4 #4 0x40339c8c in PR_Lock (lock=0x810e590) at ptsynch.c:184 184 PR_ASSERT(0 == rv); (the second one the actual crash is inside the PR_ASSERT code). So something looks like it's stomping on memory.
I have unfortunately been 100% unable to see the bug, ever. I pulled a bunch of builds last night, both debug and opt, and none of them exhibited it. Today's nightly seems fine.
Wait, rv is on the stack. Are you sure it isn't fooling you as to which thread crashed? What are you doing to produce the crashes? (I haven't been able.)
The PR_LOCK crashes were in hashtable code and were produced by trying to open a file of unknown type off the commandline: mozilla /home/bzbarsky/test.foo I can also no longer reproduce them in a build I pulled from this morning... see also bug 125967. And yes, I'm sure it was the right thread.... :)
I can't find any people who can reproduce the original crash (I've asked in IRC and people here are not seeing it). bz's crash, which is no longer happening, is filed elsewhere apparently (bug 125967), and does not appear to be related anyway. Resolving worksforme until someone sees it again. Please reopen if you are still seeing this crash.
Heh, let's try that again. worksforme.
I suck. I managed to actually click back on "Leave as NEW."
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
This could be the linux orange from yesterday... bnesse's checkin. It was backed out, which is why current builds do not have the problem. The timing seems about right....
walk84 is seeing this in an opt CVS build from today. bz and I still cannot reproduce, in debug or opt build. walk84, could you try a clobber build? bz did lots of rebuilding and pulling to try and find when the problem occurred, and eventually the problem quit occurring. Maybe it's an odd dependency problem in the tree. Changing summary to reflect what bz found (and what walk84 is seeing). This is a save/restore issue.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Summary: crash on second page load → crash when leaving page with form controls
Reducing severity since most people aren't seeing it.
Severity: blocker → critical
a clobber build did fix the problem, resolving worksforme.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago → 16 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.