125937 - crash when leaving page with form controls

Status: VERIFIED WORKSFORME

(Core :: DOM: Core & HTML, defect)

Description

[Hixie (not reading bugmail)]

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.

Comment 1

[tor]

Attachment: stack from a 2/16 13:03 pull (going from bugzilla to slashdot)

Comment 2

[tor]

Attachment: top of debug stack

Comment 3

[John Keiser (jkeiser)]

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

[tor]

2/17 4:51 pacific pull is working fine, fwiw.

Comment 5

[Boris Zbarsky [:bzbarsky]]

11:30 Pacific pull is working fine too...

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

[Boris Zbarsky [:bzbarsky]]

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

[John Keiser (jkeiser)]

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

[John Keiser (jkeiser)]

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

[Boris Zbarsky [:bzbarsky]]

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

[John Keiser (jkeiser)]

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

[John Keiser (jkeiser)]

Heh, let's try that again.  worksforme.

Comment 13

[John Keiser (jkeiser)]

I suck.  I managed to actually click back on "Leave as NEW."

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

[John Keiser (jkeiser)]

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.

Comment 16

[John Keiser (jkeiser)]

Reducing severity since most people aren't seeing it.

Comment 17

[Stephen Walker]

a clobber build did fix the problem, resolving worksforme.

Comment 18

[Vladimir Ermakov]

 verifying