Closed Bug 96232 Opened 22 years ago Closed 22 years ago

Mac build crashes randomly in HandleOSEvent() - Trunk [@ 0xffc10000 - nsMacEventHandler::HandleOSEvent]

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

PowerPC
Mac System 9.x
defect
Not set
blocker

Tracking

()

VERIFIED FIXED
mozilla0.9.4

People

(Reporter: bnesse, Assigned: sfraser_bugs)

References

Details

(Keywords: crash, regression, topcrash, Whiteboard: OSX++)

Crash Data

Attachments

(2 files)

Todays build (2001082104) has crashed on me 3 times in the last 30 minutes all
with the following stack crawl. I have filed talkback reports in each case. I
will supply the ids shortly.

 Calling chain using A6/R1 links
  Back chain  ISA  Caller
  00000000    PPC  3D1C7894  
  0DF47800    PPC  3D1B2C68  main+00130
  0DF477A0    PPC  3D1B1ED4  main1(int, char**, nsISupports*)+00D34
  0DF47440    PPC  3D01C158  nsAppShellService::Run()+00018
  0DF47400    PPC  3CCEF784  nsAppShell::Run()+00048
  0DF473B0    PPC  3CCF01D4  nsMacMessagePump::DoMessagePump()+0003C
  0DF47360    PPC  3CCF0874  nsMacMessagePump::DispatchEvent(int,
EventRecord*)+00110
  0DF47310    PPC  3CCF130C  nsMacMessagePump::DoMouseMove(EventRecord&)+00098
  0DF472C0    PPC  3CCF179C 
nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort*)+00040
  0DF47270    PPC  3CCECDA8  nsMacMessageSink::DispatchOSEvent(EventRecord&,
GrafPort*)+00038
  0DF47230    PPC  3CCE7A9C  nsMacWindow::HandleOSEvent(EventRecord&)+00020
  0DF471F0    PPC  3CCE8BDC  nsMacEventHandler::HandleOSEvent(EventRecord&)+0017C
The 3 incidents I filed are TB34321004K, TB34320756Z, TB34319468M. All were
random crashes, generally after clicking the mouse. Once switching out to the
finder, once deleting a mail message, once will just trying to look at this
mornings bug list.
Keywords: crash, regression
*** Bug 96235 has been marked as a duplicate of this bug. ***
Steps to reproduce from dup bug 96235:

> 1. Launch the browser using the build above here.(I tried on Modern theme).
> 2. Creat a new profile. (For example: 08-21-04-trunk).
> 3. Select Tasks > Mail & News
> 4. Click one of the "UNREAD MESSAGE", it crashes.
> 5. Re-launch the browser again.
> 6. Either use the same profile or creat a new profile again
> 7. Follow steps 3-4. But this time, the browser does not crash.

I just repro'd this bug again... with a slight twist. Now it crashed on a key
event and ended in JS. Talkback ID TB34322406Z.

 Calling chain using A6/R1 links
  Back chain  ISA  Caller
  00000000    PPC  3E6DA894  
  0BB93360    PPC  3E6C5C68  main+00130
  0BB93300    PPC  3E6C4ED4  main1(int, char**, nsISupports*)+00D34
  0BB92FA0    PPC  3E01A158  nsAppShellService::Run()+00018
  0BB92F60    PPC  3D9AE784  nsAppShell::Run()+00048
  0BB92F10    PPC  3D9AF1D4  nsMacMessagePump::DoMessagePump()+0003C
  0BB92EC0    PPC  3D9AF7AC  nsMacMessagePump::DispatchEvent(int,
EventRecord*)+00048
  0BB92E70    PPC  3D9B039C  nsMacMessagePump::DoKey(EventRecord&)+00030
  0BB92E20    PPC  3D9B079C 
nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort*)+00040
  0BB92DD0    PPC  3D9ABDA8  nsMacMessageSink::DispatchOSEvent(EventRecord&,
GrafPort*)+00038
  0BB92D90    PPC  3D9A6A9C  nsMacWindow::HandleOSEvent(EventRecord&)+00020
  0BB92D50    PPC  3D9A7AB0  nsMacEventHandler::HandleOSEvent(EventRecord&)+00050
  0BB92D00    PPC  3D9A8A3C  nsMacEventHandler::HandleKeyEvent(EventRecord&)+00110
  0BB92C60    PPC  3CFAF4E4  js_GetArgument+00024
  0BB92C10    PPC  3CF8F2F0  JS_GetInstancePrivate+00018
  0BB92BD0    PPC  3CF8F000  JS_InstanceOf+000A0
 Closing log
going out on a limb and marking this a smoketest blocker.
Severity: critical → blocker
Keywords: smoketest
cc'ing saari who checked in nsEventStateManager yesterday...
Keywords: smoketest
Looks like my last comment removed tingleys smoketest keyword... re-adding.
Keywords: smoketest
Um, I don't think it would be my checkin, but feel free to revert my change and
see if that helps. Is there a better stack trace? These aren't very informative.
There are other bugs with this stack that have been around for a while, like
http://bugzilla.mozilla.org/show_bug.cgi?id=94019

we need a better handle on what the crash is
My build hasn't finished yet, so I don't know any more than what you see here.
At least one of my crashes looked like it had jumped into random memory (i.e.
not code) from the HandleOSEvent() method. I assume that a bad event is being
posted into the queue, but that's just a guess.
Keeping smoketest keyword because this is a blocker, not holding the 
tree as per leaf on irc since we have plenty of pre-release time to deal 
with this anyway.
Attached file More helpful stdlog
I have attached a (hopefully) more useful log. I got it to crash in my debug
version. The crash in the log is due to the nsWindow * from the event record
(mouseEvent.widget) in HandleMouseMoveEvent() having been deleted prior to its
being passed to HandleMouseMoveEvent.
brian, do you remember what you were doing when you made this blow up?

I still don't think this was due to my checkin anyway
*** Bug 96327 has been marked as a duplicate of this bug. ***
smfr is seeing this on osx as well.
Whiteboard: OSX++
Chris, no I don't think it is either. I was mostly hoping you had some insight 
based on your event experience. I'm quite sure it's a widget thing right now. My 
last crash seemed to imply that the nsMacEventHandler was bad since it died 
calling an internal function. I'm sort of working on debugging by NS_ASSERTION 
right now...

As to what I was doing... nothing special. Sometimes it crashes when you click, 
sometimes when you type, sometimes on a simple mouse move.
okay, I'm still trying to get a good mac build for today <sigh>
I'll try to help at that point. The only major widget change I know of was
Hyatt's popup wackage on Friday. Is that when this started?
Very possibly. The last daily build I managed to get before this one was from 
late last week (8/17 maybe).
II got similar crash in this build while typing a letter or two in URL bar.
Crash occurred before the dropdown menu was displayed.  But after a few
relaunch, I have not got the crash so far. (Filed as bug 96311.)
On of the stack was:
 Calling chain using A6/R1 links
  Back chain  ISA  Caller
  00000000    PPC  3EBB7894  
  0AB06520    PPC  3EBA2C68  main+00130
  0AB064C0    PPC  3EBA1ED4  main1(int, char**, nsISupports*)+00D34
  0AB06160    PPC  3E3EA158  nsAppShellService::Run()+00018
  0AB06120    PPC  3E1A8784  nsAppShell::Run()+00048
  0AB060D0    PPC  3E1A91D4  nsMacMessagePump::DoMessagePump()+0003C
  0AB06080    PPC  3E1A97AC  nsMacMessagePump::DispatchEvent(int,
EventRecord*)+00048
  0AB06030    PPC  3E1AA39C  nsMacMessagePump::DoKey(EventRecord&)+00030
  0AB05FE0    PPC  3E1AA79C 
nsMacMessagePump::DispatchOSEventToRaptor(EventRecord&, GrafPort
*)+00040
  0AB05F90    PPC  3E1A5DA8  nsMacMessageSink::DispatchOSEvent(EventRecord&,
GrafPort*)+00038
  0AB05F50    PPC  3E1A0A9C  nsMacWindow::HandleOSEvent(EventRecord&)+00020
  0AB05F10    PPC  3E1A1AB0  nsMacEventHandler::HandleOSEvent(EventRecord&)+00050
  0AB05EC0    PPC  3E1A2A3C  nsMacEventHandler::HandleKeyEvent(EventRecord&)+00110
  0AB05E20    PPC  3E3BBE08  XPC_WN_Helper_GetProperty(JSContext*, JSObject*,
long, long*)+00
048
  0AB05DC0    PPC  3E3B9944  Throw(unsigned int, JSContext*)+0000C
  0AB05D80    PPC  3E3AD8E0  XPCThrower::Throw(unsigned int, JSContext*)+00044
  0AB05D30    PPC  3E3ADF1C  XPCThrower::BuildAndThrowException(JSContext*,
unsigned int, con
st char*)+00080
  0AB05CC0    PPC  3E3AE020  XPCThrower::ThrowExceptionObject(JSContext*,
nsIException*)+0007
8
  0AB05C40    PPC  3E391DDC  nsXPConnect::WrapNative(JSContext*, JSObject*,
nsISupports*, con
st nsID&, nsIXPConnectJSObjectHolder**)+0004C
  0AB05B70    PPC  3E3C7FC4 
XPCCallContext::XPCCallContext(XPCContext::LangType, JSContext*,
 JSObject*, JSObject*, long, unsigned int, long*, long*)+00178
  0AB05AC0    PPC  3D9AFC14  JS_BeginRequest+00028
Yes, typing in the url bar is one of the ways I have reproduced this bug.
Unfortunately, so far, the things I have identified as possible sources for the
crash haven't panned out.
no offense to joki, but i don't see him fixing this mac bug. --> saari
Assignee: joki → saari
adding Tracy (smoke-tester) since he didn't experience this bug.
I have seen this on builds from 8/21 & 8/22. It's annoying, but not a smoketest 
blocker because it's not reproducable at any particular action and doesn't 
prevent any of the smoketests from being performed.

removing smoketest keyword and reducing severity to critical
Severity: blocker → critical
Keywords: smoketest
It almost totally prevents me from typing URLs in a Mac OS X build.
Severity: critical → blocker
this just hit me today. i can't use today's bits for more than 5 minutes at a 
stretch. ugh! giving some keyword lovin'
Keywords: nsenterprise
I've been seeing this for a while (last week?)
I see it most often just moving my mouse.
My macsbug stack crawl is in nsDeleteObserved::AddDeleteObserver
called from nsMacEventDispatchHandler::SetWidgetPointed
            nsMacEventHandler::HandleMouseMoveEvent
            nsMacEventHandler::HandleOSEvent
            ...

looking at my screen, I was mousing over the icon in the toolbar (actually over 
the text below the icon) and the area where a tooltip should appear is white/
erased but no tooltip has drawn there yet.
Yes, that is it. As I was typing before I crashed :(

And the winner is...... ToolTips. Disabling tooltips is the workaround. This has
something, I don't know what yet, to do with the tooltip window.

I finally figured out a more or less reproducible test case involving selecting
and editing the last character of a url. After some trial and error testing it
appears that the crash is somehow tied to the display, or lack thereof, of the
"enter search term, keyword, etc." tooltip.
This is very easy to reproduce.
1. Hover over the url bar with the mouse so that the tooltip appears.
2. Hit any key.

The crash happens because we destroy the tooltip window in the keyDown handling, 
while we are running in methods of the nsMacWindow object that gets deleted.

I think we need a kung fu death grip here...
I'll take this. r/sr please?
Assignee: saari → sfraser
r=saari
*** Bug 96311 has been marked as a duplicate of this bug. ***
r=brade
do 3 r='s make a sr=?  ;-)
Adding topcrash keyword and Trunk [@ 0xffc10000 -
nsMacEventHandler::HandleOSEvent] to summary for tracking, this is a  topcrasher
according to the latest Talkback data.
Keywords: topcrash
Summary: Mac build crashes randomly in HandleOSEvent() → Mac build crashes randomly in HandleOSEvent() - Trunk [@ 0xffc10000 - nsMacEventHandler::HandleOSEvent]
0.9.4. Awaiting a=
Target Milestone: --- → mozilla0.9.4
*** Bug 96482 has been marked as a duplicate of this bug. ***
a=tor on behalf of drivers
Fix checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
verified fixed on mac commercial build 2001-08-23-04-trunk

Status: RESOLVED → VERIFIED
*** Bug 96637 has been marked as a duplicate of this bug. ***
*** Bug 97010 has been marked as a duplicate of this bug. ***
Crash Signature: [@ 0xffc10000 - nsMacEventHandler::HandleOSEvent]
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.