Closed Bug 124596 Opened 23 years ago Closed 22 years ago

crashing Mozilla is child's play [HandleScrollEvent]

Categories

(Core :: XUL, defect)

PowerPC
macOS
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: francis.uy, Assigned: hyatt)

References

Details

(Keywords: crash)

Attachments

(4 files)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:0.9.8+)
Gecko/20020204
BuildID:    2002020403

I had tabs open to Yahoo Mail, Google, and Tucows. My 21 month old daughter was
annoyed that I wanted to use the computer rather than watch Baby Mozart, so she
grabbed my scroll mouse and started clicking. Then Mozilla "fell down go boom".

Reproducible: Didn't try
Attached file crash log Feb 9
Severity: normal → critical
Keywords: crash
Please submit only one bug per report, and steps to reproduce.
There are 16 stacks in your attachment, many of them duplicated.
Which one was caused by the child clicking?

Probably not the first one (Date/Time:  2002-01-23 09:45:46 -0500)
#0   0x0267a914 in nsXULElement::EnsureContentsGenerated( const(void))
which has the same stacktrace as in bug 121842. Duplicate.

Going through this bug in chapters:

----
Number two: Date/Time:  2002-01-23 22:47:03 -0500
stack near tooltip code: Resembles bug 121047 / bug 120863 but not identical
 #0   0x004ea164 in 0x4ea164
 #1   0x0057c674 in nsSupportsHashtable::Get(nsHashKey *)
 #2   0x02a0cc24 in 0x2a0cc24
 #3   0x02a3e590 in nsXULElement::GetBoxObject(nsIBoxObject **)
 #4   0x02e0649c in nsXULTooltipListener::HideTooltip(void)
 #5   0x02e04204 in nsXULTooltipListener::_dt(void)
[]
----
You have added three instances of the third stack. Likely a duplicate since it
occures so frequently. 
These are identical:
Date/Time:  2002-01-24 07:21:37 -0500
Date/Time:  2002-01-24 13:31:42 -0500
Date/Time:  2002-01-29 13:20:09 -0500

Can you remember what you were doing when they occured?

Top of stack:
 #0   0x0288f938 in 0x288f938
 #1   0x0288f8c8 in 0x288f8c8
 #2   0x02888d04 in nsRuleNode::WalkRuleTree(nsStyleStructID, nsIStyleContext *)

bug 121963 and bug 121055 also land there, but stack is not identical.

----
Haven't found a match of this one yet:
Date/Time:  2002-01-29 13:05:24 -0500
#0  0x02c5deec in GetOffsetFromView__7nsFrameCFP14nsIPresContextR7nsPointPP7nsIV
#1  0x02c5def4 in GetOffsetFromView__7nsFrameCFP14nsIPresContextR7nsPointPP7nsIV
#2  0x02d4b258 in ApplyRenderingChangeToTree__FP14nsIPresContextP8nsIFrameP14nsI
#3  0x02d4ba0c in ProcessRestyledFrames__21nsCSSFrameConstructorFR17nsStyleChang
#4  0x02d4c010 in ContentStatesChanged__21nsCSSFrameConstructorFP14nsIPresContex
[]
----
This stack is a duplicate of bug 120863:
Date/Time:  2002-01-29 16:07:21 -0500
#0  0x0054f2b0 in allocate_from_fixed_pools
#1  0x0054f990 in malloc
#2  0x0054fae0 in nw(unsigned long, std::nothrow_t const &)
#3  0x0054fb44 in nw(unsigned long)
#4  0x0064fa44 in NS_AllocateContiguousHandleWithData<23nsSharedBufferHandle<w>,
#5  0x0064e370 in nsSharableString::do_AssignFromReadable(nsAString const &)
Date/Time:  2002-02-01 12:26:01 -0500
Looks like a variant of bug 122696. The stack terminates a little earlyer
Sorry about that. I wish we had Talkback. Please refer to the last crash.

It's been over a decade since I used a Unix regularly, and I wasn't admin then.
I've been running the daily maintenance command that's supposed to clear old
logs, but I guess that doesn't apply to crash logs? Am I supposed to just
manually delete them? 
More bugs should probably be extracted from this one, based on some of the other
stacks.

Your young beta-tester seemingly triggered one in scrolling code. Adding top to
summary, changing component, adding relevant stack from attachment here:

Date/Time:  2002-02-09 10:43:12 -0500
OS Version: 10.1.2 (Build 5P48)
Host:       cty96.cty.jhu.edu

Command:    Mozilla
PID:        523

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000000

Thread 0 Crashed:
#0 0x023280f8 in HandleScrollEvent(unsigned short, int, int, Point, nsIWidget *)
#1 0x023280d8 in HandleScrollEvent(unsigned short, int, int, Point, nsIWidget *)
#2 0x0232a0f4 in nsMacEventHandler::Scroll(unsigned short, int, Point const &)
#3 0x023259f0 in nsMacWindow::ScrollEventHandler(OpaqueEventHandlerCallRef *)
#4 0x73118504 in DispatchEventToHandlers
#5 0x731017b4 in SendEventToEventTargetInternal
#6 0x731b59e0 in SendEventToEventTarget
#7 0x7310d15c in HandleMouseEvent
#8 0x731ab538 in ToolboxEventDispatcherHandler
#9 0x731185b0 in DispatchEventToHandlers
#10 0x731017b4 in SendEventToEventTargetInternal
#11 0x731b59e0 in SendEventToEventTarget
#12 0x731d27f4 in ToolboxEventDispatcher
#13 0x731cfb94 in CallEventDispatchHook
#14 0x731790ac in GetOrPeekEvent
#15 0x731a086c in GetNextEventMatchingMask
#16 0x731ad904 in WNEInternal
#17 0x731c5474 in WaitNextEvent
#18 0x0232e524 in nsMacMessagePump::GetEvent(EventRecord &)
#19 0x0232e2dc in nsMacMessagePump::DoMessagePump(void)
#20 0x0232dc2c in nsAppShell::Run(void)
#21 0x022e2e3c in nsAppShellService::Run(void)
#22 0x004c8ba4 in main1(int, char **, nsISupports *)
#23 0x004c967c in main
Assignee: asa → trudelle
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
Summary: crashing Mozilla is child's play → crashing Mozilla is child's play [HandleScrollEvent]
Heh.  When my son was a toddler, he managed to crash a dBase IV beta with single
keystroke.  We never did figure out how...
->jag
Assignee: trudelle → jaggernaut
dupe of bug 110145 (by way of bug 110479) ?
Attached file crash log Feb 29
Dunno if this is the same problem as before, but I had another
HandleScrollEvent crash this morning. I was using the 20020326 trunk build.
Marking NEW to get wider audience into 'XP Toolkit/Widgets: XUL' component (by
looking at stacktrace, similar to those in bug 120863, as suggested by R.K.Aa).

Reporter, do you still crash with latest nightly build (newer than 20020326) ?
It seems like a fix from bug 120836 should be available in build 20020327+.
Assignee: jaggernaut → hyatt
Status: UNCONFIRMED → NEW
Component: XP Apps → XP Toolkit/Widgets: XUL
Ever confirmed: true
QA Contact: sairuh → shrir
I think I was wrong with last comment, because you also had reported bug 126892
which was dupe of bug 120863.
I just hope that marking it NEW will get some other people to look at it then
(sorry for the spam).
This is the only time I've had a HandleScroll crash since 6 weeks ago when I
first reported. I think I closed a background tab using right click and tried to
scroll the foreground tab. If it was fixed on the 27th that's great. If not, I
guess I'll post another crash log if it happens again.
Attached file April 8 crash log
Mozilla 2002040608 crashed twice in a handful of minutes with HandleScroll. In
the first case I was loading a background tab and attempting to scroll the
foreground. In the second case I was loading a new page in one frame (sidebar
of Yahoo mail) while attempting to scroll another (current message).
*** Bug 146539 has been marked as a duplicate of this bug. ***
*** Bug 148442 has been marked as a duplicate of this bug. ***
Still occuring on Mozilla 1.0.0.  Some combination of switching or closing tabs
followed by the scrollwheel on the mouse.
Is bug 156162 a duplicate of this one?
*** Bug 156162 has been marked as a duplicate of this bug. ***
*** Bug 158186 has been marked as a duplicate of this bug. ***
Date/Time:  2002-01-29 13:05:24 -0500
appears to be bug 166205
*** Bug 165217 has been marked as a duplicate of this bug. ***
FWIW, I haven't had a HandleScroll crash in the past 8 months, even when I
intentionally scroll in one place while loading another. And the last reported
dupe crash was in August.
Marking WFM, it doesn't show on topcrasher's list either. 
Please reopen if you crash with a recent nightly. 
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: