Closed
Bug 125937
Opened 23 years ago
Closed 23 years ago
crash when leaving page with form controls
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: ian, Assigned: alexsavulov)
Details
(Keywords: crash, regression, smoketest)
Attachments
(2 files)
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.
Reporter | ||
Updated•23 years ago
|
Comment 3•23 years ago
|
||
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.
Comment 5•23 years ago
|
||
11:30 Pacific pull is working fine too...
Comment 6•23 years ago
|
||
OK, something is weird. I tried a 19:35 pull in which I was _definitely_ seeing this crash before.... it is no longer there.
Comment 7•23 years ago
|
||
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.
Comment 8•23 years ago
|
||
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.
Comment 9•23 years ago
|
||
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.)
Comment 10•23 years ago
|
||
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.... :)
Comment 11•23 years ago
|
||
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.
Comment 12•23 years ago
|
||
Heh, let's try that again. worksforme.
Comment 13•23 years ago
|
||
I suck. I managed to actually click back on "Leave as NEW."
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Comment 14•23 years ago
|
||
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....
Comment 15•23 years ago
|
||
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
Comment 16•23 years ago
|
||
Reducing severity since most people aren't seeing it.
Severity: blocker → critical
Comment 17•23 years ago
|
||
a clobber build did fix the problem, resolving worksforme.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Updated•5 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•