Closed Bug 120863 Opened 22 years ago Closed 22 years ago

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


(Core :: XUL, defect)

Not set





(Reporter: fz.2009, Assigned: hewitt)



(Keywords: crash, testcase, topcrash+, Whiteboard: [ADT2])

Crash Data


(5 files, 1 obsolete file)

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

Reproducible: Sometimes
Steps to Reproduce:
1.Start Mozilla ( opens); check mail.
2.In browser window, open new tab on
3.In browser window, open third tab on
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:
CC pinkerton

Reporter: Can you attach a stack trace ?
Severity: blocker → critical
Keywords: crash
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.

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

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

3. Mozilla opens on

4. Command-T to open
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

*** 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
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
GNU gdb 5.0-20001113 (Apple version gdb-200) (Mon Sep  3 02:43:52 GMT 2001) (UI_OUT)
This GDB was configured as "powerpc-apple-macos10".
Reading symbols for shared libraries .... done
(gdb) run /Applications/Mozilla.18jan/ 
Starting program:
[Switching to thread 1 (process 3679 thread 0x1603)]
Reading symbols for shared libraries ...........................................
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
#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
#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
#18 0x02105c00 in
#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
probably not string land's fault, but over there first for comment.
Assignee: asa → scc
Component: Browser-General → String
QA Contact: doronr → jaggernaut
Summary: Fizzilla CFM: Random crashes with Jan 2002 builds → Random crashes with Jan 2002 builds
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.

hrm, looks like we're probably double-deleting an event listener from the
tooltip code --> hewitt
Assignee: scc → hewitt
Component: String → XP Toolkit/Widgets: XUL
Ever confirmed: true
Summary: Random crashes with Jan 2002 builds → Crashing in tooltips
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?
Target Milestone: --- → mozilla1.0
*** Bug 121047 has been marked as a duplicate of this bug. ***
*** Bug 122696 has been marked as a duplicate of this bug. ***
*** Bug 125802 has been marked as a duplicate of this bug. ***
Attached file 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.
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. ***
*** Bug 126892 has been marked as a duplicate of this bug. ***
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.
nsbeta1+ per ADT triage team
Keywords: nsbeta1nsbeta1+
QA Contact: jaggernaut → jrgm
*** Bug 128020 has been marked as a duplicate of this bug. ***
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. ***
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.
*** Bug 129900 has been marked as a duplicate of this bug. ***
Summary: Crashing in tooltips, when closing a tab → Crashing in tooltips, when closing a tab (recursion)
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
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
Keywords: topcrashtestcase, 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]
Attached patch Experimental patch (obsolete) — Splinter Review
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():

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 :-)
Attached patch patchSplinter Review
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
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.)

Closed: 22 years ago
Resolution: --- → FIXED
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.

Why should this be "fixed" ?
Resolution: FIXED → ---
Maybe this should get keyword 'review'.
> reopening !

Oops sorry. I thought my action would only change "Resolution", not "Status".
Keywords: review
Comment on attachment 75689 [details] [diff] [review]

Attachment #75689 - Flags: superreview+
Comment on attachment 75689 [details] [diff] [review]

Attachment #75689 - Flags: review+
Comment on attachment 75689 [details] [diff] [review]

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #75689 - Flags: approval+
fixed now
Closed: 22 years ago22 years ago
Resolution: --- → FIXED
*** Bug 135489 has been marked as a duplicate of this bug. ***
*** Bug 125854 has been marked as a duplicate of this bug. ***
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.
*** Bug 129013 has been marked as a duplicate of this bug. ***
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.