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

VERIFIED FIXED in mozilla1.0

Status

()

Core
XUL
--
critical
VERIFIED FIXED
16 years ago
7 years ago

People

(Reporter: FZiegler, Assigned: Joe Hewitt (gone))

Tracking

({crash, testcase, topcrash+})

Trunk
mozilla1.0
crash, testcase, topcrash+
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ADT2], crash signature)

Attachments

(5 attachments, 1 obsolete attachment)

(Reporter)

Description

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

Reporter: Can you attach a stack trace ?
Severity: blocker → critical
Keywords: crash
(Reporter)

Comment 2

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

(Reporter)

Comment 3

16 years ago
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
(Reporter)

Comment 4

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

16 years ago
probably not string land's fault, but over there first for comment.
Assignee: asa → scc
Component: Browser-General → String
QA Contact: doronr → jaggernaut
(Reporter)

Updated

16 years ago
Summary: Fizzilla CFM: Random crashes with Jan 2002 builds → Random crashes with Jan 2002 builds
(Reporter)

Comment 6

16 years ago
Created attachment 66248 [details]
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
hrm, looks like we're probably double-deleting an event listener from the
tooltip code --> hewitt
Assignee: scc → hewitt
Status: UNCONFIRMED → NEW
Component: String → XP Toolkit/Widgets: XUL
Ever confirmed: true
Summary: Random crashes with Jan 2002 builds → Crashing in tooltips
(Reporter)

Comment 8

16 years ago
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?
Keywords: nsbeta1
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
(Assignee)

Comment 9

16 years ago
*** Bug 121047 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 10

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

Comment 11

16 years ago
*** Bug 125802 has been marked as a duplicate of this bug. ***
Created attachment 69907 [details]
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.
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

16 years ago
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.
*** Bug 127701 has been marked as a duplicate of this bug. ***

Comment 16

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

Comment 17

16 years ago
Created attachment 71349 [details]
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.
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

16 years ago
nsbeta1+ per ADT triage team
Keywords: nsbeta1 → nsbeta1+

Updated

16 years ago
QA Contact: jaggernaut → jrgm
*** Bug 128020 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 21

16 years ago
bug 122887 and bug 128986 also look like dupes of this bug.
Summary: Crashing in tooltips → Crashing in tooltips, when closing a tab
*** Bug 122887 has been marked as a duplicate of this bug. ***

Comment 23

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

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

Updated

16 years ago
Summary: Crashing in tooltips, when closing a tab → Crashing in tooltips, when closing a tab (recursion)

Comment 25

16 years ago
ADT2 per ADT triage.
Whiteboard: [ADT2]
*** Bug 132689 has been marked as a duplicate of this bug. ***
from the dupe : OS:all
Keywords: topcrash
OS: MacOS X → All
Hardware: Macintosh → All

Comment 28

16 years ago
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).
Keywords: topcrash → testcase, topcrash+
Summary: Crashing in tooltips, when closing a tab (recursion) → Crashing in tooltips, when closing a tab (recursion) - Trunk M099 [@ ntdll.dll - nsSharableString::do_AssignFromReadable]
(Reporter)

Comment 29

16 years ago
Created attachment 75584 [details] [diff] [review]
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 :-)
(Assignee)

Comment 30

16 years ago
Created attachment 75689 [details] [diff] [review]
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?
Attachment #75584 - Attachment is obsolete: true
(Reporter)

Comment 31

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

 
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Reporter)

Comment 32

16 years ago
Created attachment 75957 [details]
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.
reopening !

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

Reporter: 
Why should this be "fixed" ?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Maybe this should get keyword 'review'.
(Reporter)

Comment 35

16 years ago
> reopening !

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

Comment 36

16 years ago
Comment on attachment 75689 [details] [diff] [review]
patch

sr=blake
Attachment #75689 - Flags: superreview+

Comment 37

16 years ago
Comment on attachment 75689 [details] [diff] [review]
patch

r=jag
Attachment #75689 - Flags: review+

Comment 38

16 years ago
Comment on attachment 75689 [details] [diff] [review]
patch

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #75689 - Flags: approval+
(Assignee)

Comment 39

16 years ago
fixed now
Status: REOPENED → RESOLVED
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED
*** Bug 135489 has been marked as a duplicate of this bug. ***

Comment 41

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

Comment 42

16 years ago
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.
Status: RESOLVED → VERIFIED
(Reporter)

Comment 43

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

Updated

10 years ago
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Crash Signature: [@ ntdll.dll - nsSharableString::do_AssignFromReadable]
You need to log in before you can comment on or make changes to this bug.