Closed Bug 120863 Opened 22 years ago Closed 22 years ago
Crashing in tooltips, when closing a tab (recursion) - Trunk M099 [@ ntdll
.dll - ns Sharable String::do _Assign From Readable]
3.82 KB, text/plain
32.39 KB, text/plain
35.96 KB, text/plain
1.01 KB, patch
|Details | Diff | Splinter Review|
3.35 KB, text/plain
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
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 ~/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: 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 /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
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. (*)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
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?
Status: NEW → ASSIGNED
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. ***
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.
*** 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.
*** Bug 132689 has been marked as a duplicate of this bug. ***
from the dupe : OS:all
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 platforms).
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 :-)
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.)
Status: ASSIGNED → RESOLVED
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. Reporter: Why should this be "fixed" ?
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Maybe this should get keyword 'review'.
> reopening ! Oops sorry. I thought my action would only change "Resolution", not "Status".
Comment on attachment 75689 [details] [diff] [review] patch sr=blake
Attachment #75689 - Flags: superreview+
Comment on attachment 75689 [details] [diff] [review] patch r=jag
Attachment #75689 - Flags: review+
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+
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 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.
Status: RESOLVED → VERIFIED
*** 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.