Closed Bug 723201 Opened 12 years ago Closed 6 years ago

Crash in objc_send(), -[BaseWindow trackingAreaView]


(Core :: Widget: Cocoa, defect)

Not set





(Reporter: humph, Unassigned)



(Keywords: crash)

Crash Data


(1 file)

I'm working on the mouse lock implementation (bug 633602) , and when I updated to trunk today (c538da196e34) and ran our tests, I started crashing 2/3 runs:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00007fff853e4f0c in objc_msgSend ()

#0  0x00007fff853e4f0c in objc_msgSend ()
#1  0x00000001026b143a in -[BaseWindow trackingAreaView] (self=0x11a003960, _cmd=0x103445428) at /Users/dave/repos/mozilla-central/widget/cocoa/
#2  0x00000001026b13a5 in -[BaseWindow removeTrackingArea] (self=0x11a003960, _cmd=0x103445415) at /Users/dave/repos/mozilla-central/widget/cocoa/
#3  0x00000001026b31f5 in -[BaseWindow dealloc] (self=0x11a003960, _cmd=0x7fff82cb4118) at /Users/dave/repos/mozilla-central/widget/cocoa/
#4  0x00007fff8401ef93 in __CFArrayReleaseValues ()
#5  0x00007fff83ffca73 in _CFRelease ()
#6  0x00007fff840261d6 in _CFAutoreleasePoolPop ()
#7  0x00007fff809d70b3 in -[NSAutoreleasePool release] ()
#8  0x00000001026acb92 in nsAppShell::AfterProcessNextEvent (this=0x117e52ec0, aThread=0x100335c60, aRecursionDepth=0) at /Users/dave/repos/mozilla-central/widget/cocoa/
#9  0x00000001029be219 in nsThread::ProcessNextEvent (this=0x100335c60, mayWait=false, result=0x7fff5fbfc93f) at /Users/dave/repos/mozilla-central/xpcom/threads/nsThread.cpp:670
#10 0x0000000102950c02 in NS_ProcessPendingEvents_P (thread=0x100335c60, timeout=20) at /Users/dave/repos/mozilla-central/objdir-debug/xpcom/build/nsThreadUtils.cpp:195
#11 0x00000001026ff6dd in nsBaseAppShell::NativeEventCallback (this=0x117e52ec0) at /Users/dave/repos/mozilla-central/widget/xpwidgets/nsBaseAppShell.cpp:130
#12 0x00000001026ad686 in nsAppShell::ProcessGeckoEvents (aInfo=0x117e52ec0) at /Users/dave/repos/mozilla-central/widget/cocoa/
#13 0x00007fff8403f3d1 in __CFRunLoopDoSources0 ()
#14 0x00007fff8403d5c9 in __CFRunLoopRun ()
#15 0x00007fff8403cd8f in CFRunLoopRunSpecific ()
#16 0x00007fff8a4757ee in RunCurrentEventLoopInMode ()
#17 0x00007fff8a4755f3 in ReceiveNextEventCommon ()
#18 0x00007fff8a4754ac in BlockUntilNextEventMatchingListInMode ()
#19 0x00007fff825bfeb2 in _DPSNextEvent ()
#20 0x00007fff825bf801 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#21 0x00000001026ab93e in -[GeckoNSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] (self=0x117fc2e50, _cmd=0x7fff82cb7138, mask=18446744073709551615, expiration=0x11c012f80, mode=0x7fff708bd390, flag=1 '\001') at /Users/dave/repos/mozilla-central/widget/cocoa/
#22 0x00007fff8258568f in -[NSApplication run] ()
#23 0x00000001026acf88 in nsAppShell::Run (this=0x117e52ec0) at /Users/dave/repos/mozilla-central/widget/cocoa/
#24 0x000000010240945d in nsAppStartup::Run (this=0x117fc36a0) at /Users/dave/repos/mozilla-central/toolkit/components/startup/nsAppStartup.cpp:220
#25 0x000000010124ca87 in XRE_main (argc=6, argv=0x7fff5fbfefb8, aAppData=0x100007220) at /Users/dave/repos/mozilla-central/toolkit/xre/nsAppRunner.cpp:3537
#26 0x00000001000013b6 in do_main (exePath=0x7fff5fbfeb80 "/Users/dave/repos/mozilla-central/objdir-debug/dist/", argc=6, argv=0x7fff5fbfefb8) at /Users/dave/repos/mozilla-central/browser/app/nsBrowserApp.cpp:205
#27 0x0000000100001b1f in main (argc=6, argv=0x7fff5fbfefb8) at /Users/dave/repos/mozilla-central/browser/app/nsBrowserApp.cpp:295

I'll try to see if I can reduce our tests to get STR for this.  I'm not sure if this is the same as bug 720390, but it looks similar.  I'm also on 10.6.8.
Crash Signature: [@ -[BaseWindow trackingAreaView] ]
See Also: → 720390
Here's the patch I'm using (apply against c538da196e34).  When I run my tests (dom/tests/mochitest/pointerlock), like so, it will often crash (not every time):

python ./objdir-debug/_tests/testing/mochitest/ --debugger=gdb --test-path=dom/tests/mochitest/pointerlock

I can't seem to reduce it more than that :(
I am starting to suspect that this is related to having a dual-monitor setup.  I can't reproduce with only 1.
I'm hitting this a ton today as I try to finish this mouse lock patch, and have been able to isolate it to one of my tests:

var pointer = navigator.mozPointer;
var div = document.getElementById("div");

div.addEventListener("mozpointerlocklost", function() {
  is(pointer.isLocked, false, "Mouselocklost event should trigger " +
     "when window loses focus and mouse should be unlocked");
}, false);

document.addEventListener("mozfullscreenchange", function() {
  if (document.mozFullScreen && document.mozFullScreenElement === div) {
    // Mouse should be locked if the element is in fullscreen mode
    pointer.lock(div, function () {
      // Test if mouse is locked when success callback is dispatched
      ok(pointer.isLocked, "Success Callback - mouse should be locked");
      // Open a new window to switch focus and blur the current window
      // On opening a new window, the mozpointerlocklost should trigger
      var newWindow =;
}, false);

function start() {
  SimpleTest.waitForFocus(function() {

I should note that this test is run in a child window from the main test window, in order to be able to go into fullscreen (i.e., not be run inside an iframe).  I have since rewritten it to have it work more reliably, and I wonder if the issue is somehow related to the test-child-window opening a second child window and it being closed out of order, some fullscreen or pointer-lock state still being in effect, etc.  Once again, I'm hitting this with a dual monitor setup.
> Once again, I'm hitting this with a dual monitor setup.

I hope and assume the "official" build machines don't have dual monitors.

I won't be able to do much about these until I have my own dual-monitor setup ... which (for several reasons) won't be for a while.
Yeah, this isn't a main use case, and I don't mean to add pressure.  Just wanted to brain-dump what I was seeing before I moved on.
> Just wanted to brain-dump what I was seeing before I moved on.

Thanks!  That'll be useful when I do get around to fixing this.
Humph, are you still able to reproduce this?  If so do you have the RoboForm extension?  And do the crashes keep happening if you remove that extension?

If your answers are all "Yes", then this bug is a dup of bug 738640, which I've now fixed.  You'll want to try my tryserver build when it becomes available.
> And do the crashes keep happening if you remove that extension?

Ooops.  I want the answer to this to be "No".

I should have rephrased it:

And do the crashes stop happening if you remove that extension?
Closing because no crash reported since 12 weeks.
Closed: 6 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.