120863 - Crashing in tooltips, when closing a tab (recursion) - Trunk M099 [@ ntdll.dll - nsSharableString::do_AssignFromReadable]

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[FZiegler]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.7) Gecko/20011221
BuildID:    2002011803

Browser crashes, often (but not always) within seconds after closing a tab in a
browser window. Following is a sequence which caused it twice today, the first
time under build 2002011803, the second time under milestone 0.9.7 (build
2001122106). 

Reproducible: Sometimes
Steps to Reproduce:
1.Start Mozilla (http://www.mozilla.org/start opens); check mail.
2.In browser window, open new tab on http://slashdot.org
3.In browser window, open third tab on
http://www.linuxdevices.com/articles/AT8267298734.html
4.Close third tab.

Actual Results:  Browser crashes, with system message "The application Mozilla
has unexpectedly quit." No console message nor stack trace is generated, despite
having activated CrashReporter in the console preferences.

Expected Results:  Tab closes.

Above URLs are just an example -- same thing occurs quite randomly, several
times a day. Mostly within seconds (but not quite immediately) after closing a
tab, but I've also seen it after closing an entire browser window (using OS X's
red close button).

This started in mid-January, perhaps with the nightly build of January 15.
Moreover, *earlier* builds such as milestone 0.9.7 also exhibit this behavior,
once they are launched with a ~/Library/Mozilla/ folder modified (or even newly
generated) by a build such as 2002011803.

For further details, see this thread:
http://groups.google.com/groups?threadm=160120021311333976%25nguyenhm16%40no.spam.please.yahoo.com

Comment 1

[Matthias Versen [:Matti]]

CC pinkerton

Reporter: Can you attach a stack trace ?

Comment 2

[FZiegler]

No, I can't :-(  As mentioned in the original report, CrashReporter has failed
to generate a stack trace for any of those crashes. No console message, nothing
in      ~/Library/Logs, which is why I think this is different from bug 93458 or
bug 114074.

I'll be glad to try any other diagnostic methods you may suggest, though. (I
have the Sep 2001 Apple Dev Tools installed, though not the Dec 2001 ones.) I'm
sorry that I can't come up with anything more reproducible at this point, but
the problem is definitely there.

The thread I mentioned is in news:netscape.public.mozilla.macosx; it has a few
more messages (and crash reports, and speculation about pref file corruption)
than Google currently holds.

Comment 3

[FZiegler]

OK, here are steps which *always* cause the crash, under either of the
following builds:

- 2001-12-21-06 (= Mozilla 0.9.7)
- 2002-01-07-03
- 2002-01-15-18
- 2002-01-17-03
- 2002-02-18-03.

NOTE: I've tested this on both an iBook 500 MHz/OSX 10.1 (5G64) and an
iMac 233/OS X 10.1.1 (5M28). Also, I verified that these steps *never*
cause Mozilla 0.9.6 to crash.


1. Remove ~/Library/Mozilla/, and remove all things Mozilla in
~/Library/Preferences/.

2. Lauch the build. When the "Confirm Migration" window appears, click
"Manage Profiles", "Create Profile", "Next", "Finish", "Start Mozilla".

3. Mozilla opens on http://www.mozilla.org/start/

4. Command-T to open http://www.math.psu.edu/MathLists/DeptUSA.html
in a new tab. (This page is an alphabetic list of web sites.)

5. Open the first 6 sites of the list (Abilene to Allegheny) in new
tabs, using click --> Open in New Tab.

6. Click all 8 tabs in succession (left to right) to verify that they
are done loading. Use the Stop button if necessary.

7. Start closing the tabs in succession (right to left) using Command-W.


RESULT: Mozilla "quits unexpectedly" at some point -- usually upon
closing the second or third tab. 

NOTE: No stack trace is generated. The console shows an error message
like the one below, but this is in fact generated at the end of step 2
above.

*** malloc[3041]: Deallocation of a pointer not malloced: 0xffffffff;
This could be a double free(), or free() called with the middle of an
allocated block; Try setting environment variable MallocHelp to see
tools to help debug

Comment 4

[FZiegler]

Here is a backtrace obtained from gdb, after performing the 7 steps above with
build 2002011803. I hope the relevant info is there, let me know if you need more. 



[localhost:~] fz% gdb
/System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp
GNU gdb 5.0-20001113 (Apple version gdb-200) (Mon Sep  3 02:43:52 GMT 2001) (UI_OUT)
<snip>
<snip>
<snip>
This GDB was configured as "powerpc-apple-macos10".
Reading symbols for shared libraries .... done
(gdb) run /Applications/Mozilla.18jan/Mozilla.app/Contents/MacOS/Mozilla 
Starting program:
/System/Library/Frameworks/Carbon.framework/Versions/A/Support/LaunchCFMApp
/Applications/Mozilla.18jan/Mozilla.app/Contents/MacOS/Mozilla
[Switching to thread 1 (process 3679 thread 0x1603)]
Reading symbols for shared libraries ...........................................
done
<snip>
<snip>
<snip>
Reading symbols for shared libraries . done

Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00524250 in get_malloc_pool ()
(gdb) info threads
  8 process 3679 thread 0x254b  0x7003fe48 in semaphore_wait_signal_trap ()
  7 process 3679 thread 0x240b  0x70001308 in mach_msg_overwrite_trap ()
  6 process 3679 thread 0x232b  0x70001308 in mach_msg_overwrite_trap ()
  5 process 3679 thread 0x2203  0x7003fe48 in semaphore_wait_signal_trap ()
  4 process 3679 thread 0x2103  0x70043988 in semaphore_timedwait_signal_trap ()
  3 process 3679 thread 0x2003  0x7003fe48 in semaphore_wait_signal_trap ()
  2 process 3679 thread 0x1e37  0x7000530c in syscall ()
* 1 process 3679 thread 0x1603  0x00524250 in get_malloc_pool ()
(gdb) backtrace 20
#0  0x00524250 in get_malloc_pool ()
#1  0x00524988 in malloc ()
#2  0x00524ae0 in __nw__FUlRCQ23std9nothrow_t ()
#3  0x00524b44 in __nw__FUl ()
#4  0x00622e34 in
NS_AllocateContiguousHandleWithData<23nsSharedBufferHandle<w>,9nsAString>__FPC23nsSharedBufferHandle<w>UiPC9nsAString
()
#5  0x00621760 in do_AssignFromReadable__16nsSharableStringFRC9nsAString ()
#6  0x00617510 in AssignFromReadable__9nsAStringFRC9nsAString ()
#7  0x0062091c in __ct__19nsPromiseFlatStringFRC9nsAString ()
#8  0x00574540 in PromiseFlatString__FRC9nsAString ()
#9  0x00574358 in GetAtomHashEntry__FRC9nsAString ()
#10 0x005745a8 in NS_NewAtom__FRC9nsAString ()
#11 0x02105ba4 in
RemoveEventListenerByType__22nsEventListenerManagerFP19nsIDOMEventListenerRC9nsAStringi
()
#12 0x022ec820 in
RemoveEventListener__13nsXULDocumentFRC9nsAStringP19nsIDOMEventListeneri ()
#13 0x02af706c in DestroyTooltip__20nsXULTooltipListenerFv ()
#14 0x02af6528 in HideTooltip__20nsXULTooltipListenerFv ()
#15 0x02af4204 in __dt__20nsXULTooltipListenerFv ()
#16 0x02af43f4 in Release__20nsXULTooltipListenerFv ()
#17 0x02104e4c in
RemoveEventListener__22nsEventListenerManagerFP19nsIDOMEventListener14EventArrayTypeiP9nsHashKeyi
()
#18 0x02105c00 in
RemoveEventListenerByType__22nsEventListenerManagerFP19nsIDOMEventListenerRC9nsAStringi
()
#19 0x02320480 in
RemoveEventListener__12nsXULElementFRC9nsAStringP19nsIDOMEventListeneri ()
(More stack frames follow...)
(gdb) info frame
Stack level 0, frame at 0xbff80010:
 pc = 0x524250 in get_malloc_pool; saved pc 0x524988
 (FRAMELESS), called by frame at 0xbff80010
 Arglist at 0xbff80010, args: 
 Locals at 0xbff80010, Previous frame's sp is 0xbff80010
(gdb) quit

Comment 5

[timeless]

probably not string land's fault, but over there first for comment.

Comment 6

[FZiegler]

Attachment: Backtrace (Mach-O build)

Just tried the latest Mach-O build(*) and sure enough, the same 7 steps led to
the same crash as with CFM builds. The backtrace is slightly different, so I'm
attaching it. Also checked that the previous Mach-O build (from Jan 11) gives
the same crash and backtrace.

(*)http://ftp.mozilla.org/pub/mozilla/nightly/2002-01-23-17-trunk/mozilla-macho-macosx-trunk.dmg.gz

Comment 7

[Mike Pinkerton (not reading bugmail)]

hrm, looks like we're probably double-deleting an event listener from the
tooltip code --> hewitt

Comment 8

[FZiegler]

Thanks, that must be it. The crashes disappear as soon as I disable "Show
Tooltips" in Mozilla > Preferences > Appearance.

Assuming the bug can't be fixed for 0.9.8, may I suggest mentioning this
workaround in the release notes?

Comment 9

[Joe Hewitt (gone)]

*** Bug 121047 has been marked as a duplicate of this bug. ***

Comment 10

[Joe Hewitt (gone)]

*** Bug 122696 has been marked as a duplicate of this bug. ***

Comment 11

[R.K.Aa.]

*** Bug 125802 has been marked as a duplicate of this bug. ***

Comment 12

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Attachment: CFM CrashReporter Log

Not that I know much about Mozilla code, but this looks alot like an infinite
loop exhausting memory.  It might also explain the nice massage I got from my
laptop hard drive thrashing right before crash.

Comment 13

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Watching another crash in progress only saw the app memory usage go from 33.1%
to 33.2% (128MB machine).  No VM thrashing this time.

Comment 14

[Erik Neuenschwander]

Two comments.  First, I can't repro this bug on Windows -- the tooltip gets
destroyed on any keypress, so the ctrl of ctrl+f4 kills it.

Second, I attached two crashlogs to the bug I reported (a dup of this): bug
125802.  (If it doesn't hyperlink that can someone tell me the trick?)  Maybe
they'll be helpful.

Comment 15

[Matthias Versen [:Matti]]

*** Bug 127701 has been marked as a duplicate of this bug. ***

Comment 16

[Frankie]

*** Bug 126892 has been marked as a duplicate of this bug. ***

Comment 17

[Frankie]

Attachment: crash log, Feb 25 build

This is the only crash I get any more (other than bug 107806 for connoisseurs),
but boy does it happen a lot.

Comment 18

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Hrmmm, I get this on my G3/400 laptop (10.1.3) every time I close a tab, and
never on my G4/400 Desktop (10.1.3).  I can't see how that makes any kind of
sense.  My profile is probably different, but that's about it.  The G4 Mozilla
is set to show tooltips, so that's not it.

Comment 19

[Peter Trudelle]

nsbeta1+ per ADT triage team

Comment 20

[sairuh (rarely reading bugmail)]

*** Bug 128020 has been marked as a duplicate of this bug. ***

Comment 21

[FZiegler]

bug 122887 and bug 128986 also look like dupes of this bug.

Comment 22

[Matthias Versen [:Matti]]

*** Bug 122887 has been marked as a duplicate of this bug. ***

Comment 23

[Frankie]

This problem occurs if and only if you close the active tab. You can safely
right-click on inactive tabs and close them. I'm this was understood already,
but it isn't explicitly stated in the comments.

Comment 24

[John Morrison]

*** Bug 129900 has been marked as a duplicate of this bug. ***

Comment 25

[Jaime Rodriguez, Jr.]

ADT2 per ADT triage.

Comment 26

[Matthias Versen [:Matti]]

*** Bug 132689 has been marked as a duplicate of this bug. ***

Comment 27

[Matthias Versen [:Matti]]

from the dupe : OS:all

Comment 28

[Jay Patel [:jay]]

Moving over summary info from duped bug 132689.  Also adding testcase keyword
and topcrash+.  This has been a topcrasher with Mozilla 0.9.9 (apparently on all
platforms).

Comment 29

[FZiegler]

Attachment: Experimental patch

The sequence of events is:

(1)  HideTooltip		 .../nsXULTooltipListener.cpp#492
(2)  DestroyTooltip		 .../nsXULTooltipListener.cpp#618
(3)  RemoveEventListener	 .../nsXULElement.cpp#1824
(4)  RemoveEventListenerByType	 .../nsEventListenerManager.cpp#792
(5)  RemoveEventListener	 .../nsEventListenerManager.cpp#502
(6)  Release			 .../nsXULTooltipListener.cpp#85
(7)  _dt			 .../nsXULTooltipListener.cpp#74

Then (7) loops back into (1), because line 74 calls HideTooltip():
http://lxr.mozilla.org/mozilla/source/layout/xul/base/src/nsXULTooltipListener.cpp#74


Shouldn't this line be subject to verification that the listener still exists?
As a test, I built with the attached patch (which merely removes the line).
This appears to fix our bug, but of course, I have no idea what havoc it might
cause elsewhere :-)

Comment 30

[Joe Hewitt (gone)]

Attachment: patch

Thanks for the patch, hysterion.  We can't remove that call to HideTooltip as
it is required to destroy the tooltip if the listener goes away.  What we can
do, though, is release our hold on mCurrentTooltip just before calling
RemoveEventListener, which should prevent the recursion.

I can't repro the crash, so I can't really test this patch.  Can somebody who
can repro the crash test this patch for me?

Comment 31

[FZiegler]

I think you nailed it for good :-)

I made a build with your patch last night, and it resists all my attempts to
crash it with the steps of comment #3.

(Marking fixed.)

 

Comment 32

[FZiegler]

Attachment: Stack trace (after bugfix)

Attaching, as further evidence, the stack trace obtained with a break point
inside the destructor.

It shows what happens on closing a tab with command-W. After hitting "continue"
Mozilla hums along just fine, whereas without the patch, we'd have endless
iterations of lines #0 through #6.

Comment 33

[Matthias Versen [:Matti]]

reopening !

This patch is not reviewed and not checked into the tree.

Reporter: 
Why should this be "fixed" ?

Comment 34

[Bill McGonigle (not currently reading bugmail; please contact directly)]

Maybe this should get keyword 'review'.

Comment 35

[FZiegler]

> reopening !

Oops sorry. I thought my action would only change "Resolution", not "Status".

Comment 36

[Blake Ross]

Comment on attachment 75689 [details] [diff] [review]
patch

sr=blake

Comment 37

[jag (Peter Annema)]

Comment on attachment 75689 [details] [diff] [review]
patch

r=jag

Comment 38

[Asa Dotzler [:asa]]

Comment on attachment 75689 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 39

[Joe Hewitt (gone)]

fixed now

Comment 40

[Matthias Versen [:Matti]]

*** Bug 135489 has been marked as a duplicate of this bug. ***

Comment 41

[Greg K.]

*** Bug 125854 has been marked as a duplicate of this bug. ***

Comment 42

[greer]

Verified fixed. There are no instances of this signature (either as a top frame
in the stack or under ntdll.dll) on the Trunk or Branch in the Talkback data.

Comment 43

[FZiegler]

*** Bug 129013 has been marked as a duplicate of this bug. ***