crash when leaving page with form controls

VERIFIED WORKSFORME

Status

()

Core
HTML: Form Submission
--
critical
VERIFIED WORKSFORME
16 years ago
16 years ago

People

(Reporter: Hixie (not reading bugmail), Assigned: Alexandru Savulov)

Tracking

({crash, regression, smoketest})

Trunk
x86
All
crash, regression, smoketest
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
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

16 years ago
Keywords: crash, regression, smoketest

Comment 1

16 years ago
Created attachment 69886 [details]
stack from a 2/16 13:03 pull (going from bugzilla to slashdot)

Comment 2

16 years ago
Created attachment 69895 [details]
top of debug stack

Comment 3

16 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 4

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

Comment 8

16 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

16 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.)
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

Comment 17

16 years ago
a clobber build did fix the problem, resolving worksforme.
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → WORKSFORME

Comment 18

16 years ago
 verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.