Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0xffffffff 0xfffeff20 in objc_msgSend_rtp () (gdb) bt

0 0xfffeff20 in objc_msgSend_rtp ()

1 0x937a6524 in -[NSApplication sendEvent:] ()

2 0x9379d960 in -[NSApplication run] ()

3 0x017132d8 in nsAppShell::Run ()

4 0x13538f20 in nsAppStartup::Run ()

5 0x0003e628 in XRE_main ()

6 0x00003a40 in main ()

(gdb) q

The selector is indeed sendEvent: so this doesn't help us. What it looks like is that the menupopup gets destroyed and we don't realize it, try to pass it a message, and boom. This should be fixed for the next release.

Full trace in Debug was not particularly revealing.

++DOMWINDOW == 33 (0x5bb275a0) [serial = 41] [outer = 0x5b616d10]

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x696d6167 0xfffeff20 in objc_msgSend_rtp () (gdb) bt

0 0xfffeff20 in objc_msgSend_rtp ()

1 0x937a6524 in -[NSApplication sendEvent:] ()

2 0x9379d960 in -[NSApplication run] ()

3 0x1a1bbff4 in nsAppShell::Run (this=0x3916dd0) at /Volumes/BruceDeuce/src/mozilla-central/widget/src/cocoa/nsAppShell.mm:747

4 0x52c57950 in nsAppStartup::Run (this=0x397ab20) at /Volumes/BruceDeuce/src/mozilla-central/toolkit/components/startup/src/nsAppStartup.cpp:191

5 0x0021609c in XRE_main (argc=1, argv=0xbffff918, aAppData=0x3909350) at /Volumes/BruceDeuce/src/mozilla-central/toolkit/xre/nsAppRunner.cpp:3682

6 0x000037e0 in main (argc=1, argv=0xbffff918) at /Volumes/BruceDeuce/src/mozilla-central/browser/app/nsBrowserApp.cpp:158

(gdb) bt full

0 0xfffeff20 in objc_msgSend_rtp ()

No symbol table info available.

1 0x937a6524 in -[NSApplication sendEvent:] ()

No symbol table info available.

2 0x9379d960 in -[NSApplication run] ()

No symbol table info available.

3 0x1a1bbff4 in nsAppShell::Run (this=0x3916dd0) at /Volumes/BruceDeuce/src/mozilla-central/widget/src/cocoa/nsAppShell.mm:747

    _exn = (NSException *) 0x90005f3c

4 0x52c57950 in nsAppStartup::Run (this=0x397ab20) at /Volumes/BruceDeuce/src/mozilla-central/toolkit/components/startup/src/nsAppStartup.cpp:191

    rv = 0

5 0x0021609c in XRE_main (argc=1, argv=0xbffff918, aAppData=0x3909350) at /Volumes/BruceDeuce/src/mozilla-central/toolkit/xre/nsAppRunner.cpp:3682

    appStartup = {

mRawPtr = 0x397ab20 } shuttingDown = 0 cmdLine = { mRawPtr = 0x58c4e870 } workingDir = { mRawPtr = 0x563ddef0 } xpcom = { mServiceManager = 0x3916684, static gNativeAppSupport = 0x390aab0 } prefs = { mRawPtr = 0x392ee70 } flagFile = { mRawPtr = 0x3915b60 } appInitiatedRestart = 0 nativeApp = { mRawPtr = 0x390aab0 } startOffline = 0 profLD = { mRawPtr = 0x3915ae0 } fFlagFile = { mRawPtr = 0x3915b60 } cachesOK = 0 updRoot = { mRawPtr = 0x390a910 } profD = { mRawPtr = 0x3915a60 } canRun = 1 persistent = 1 profileLock = { mRawPtr = 0x3915820 } profileName = { = { = { = { mData = 0x39151c8 "default", mLength = 7, mFlags = 65541 }, }, members of nsFixedCString: mFixedCapacity = 63, mFixedBuf = 0xbffff644 "" }, members of nsCAutoString: mStorage = "\000\000?y\000\000\023??\b?????\003??T??\n?\002?[\b????????\000\000\000\000/\000\000\000??????|????\002??̿???" } version = { = { = { = { mData = 0xbffff698 "4.0b8pre_20101104124117/20101104124117", mLength = 38, mFlags = 65553 }, }, members of nsFixedCString: mFixedCapacity = 63, mFixedBuf = 0xbffff698 "4.0b8pre_20101104124117/20101104124117" }, members of nsCAutoString: mStorage = "4.0b8pre_20101104124117/20101104124117\000???? \000%?D??WH\003??\020???0\003??`" } osABI = { = { = { mData = 0x25b164 "Darwin_ppc-gcc3", mLength = 15, mFlags = 1 }, }, } versionOK = 1 rv = 0 ar = ARG_NONE home = 0xbffffc21 "/home/spectre" override = 0x0 appData = { = { size = 56, directory = 0x390a910, vendor = 0x390a990 "Mozilla", name = 0x390a520 "Firefox", version = 0x390a530 "4.0b8pre", buildID = 0x3908b20 "20101104124117", ID = 0x390a8d0 "{ec8030f7-c20a-464f-9b0e-13a3a9e97384}", copyright = 0x0, flags = 6, xreDirectory = 0x390a7a0, minVersion = 0x3908b30 "2.0b8pre", maxVersion = 0x3908c20 "2.0b8pre", crashReporterURL = 0x390aa20 "https://crash-reports.mozilla.com/submit?id=ec8030f7-c20a-464f-9b0e-13a3a9e97384&version=4.0b8pre&buildid=20101104124117", profile = 0x0 }, } log = {} dirProvider = { = { = { = { _vptr$nsISupports = 0x293018 }, }, }, = { = { _vptr$nsISupports = 0x29303c }, }, members of nsXREDirProvider: mAppProvider = { mRawPtr = 0x0 }, mGREDir = { mRawPtr = 0x390a7a0 }, mXULAppDir = { mRawPtr = 0x390a910 }, mProfileDir = { mRawPtr = 0x3915a60 }, mProfileLocalDir = { mRawPtr = 0x3915ae0 }, mProfileNotified = 1 '\001', mAppBundleDirectories = { = { mArray = { mImpl = 0x0 } }, }, mExtensionDirectories = { = { mArray = { mImpl = 0x563a9440 } }, }, mThemeDirectories = { = { mArray = { mImpl = 0x563b2410 } }, } } crashreporterEnv = 0x0 i = 1

6 0x000037e0 in main (argc=1, argv=0xbffff918) at /Volumes/BruceDeuce/src/mozilla-central/browser/app/nsBrowserApp.cpp:158

    log = {<No data fields>}
    appini = {

mRawPtr = 0x39089e0 } rv = 0 appEnv = 0x0 appDataFile = 0x0 appData = (nsXREAppData *) 0x3909350 result = 13004 (gdb) q

If the context menu opens with right-click, then it seems we can do this all the live-long day and there is no crash. If the context menu opens with click-hold, then within a click or two it's dead. This implies the event handler is the code at fault, not the menu.

So, the workaround is always use right-click for now, too.

Added some logging in nsCocoaWindow so we could see better what was going on. It appears that the sendEvent in PopupWindow is the offender.

popup created processing PopupWindow event 2010-11-16 23:06:10.328 firefox-bin[13904] Mozilla has caught an Obj-C exception

If we suppress the [super sendEvent:....]s in PopupWindow, however, the crash still occurs. This is the symptom, not the disease. NSApp continues to pass the event to the bad object. At times objc will complain about a double freed object, but I can't get it to do this consistently to hand to malloc_history. We'll try more tonight.

The crash is wallpapered if we change browser/base/content/browser.js to disable click-and-hold handlers. However, this turns off left-click-hold to get the back menu. Right-click works, so this is a shippable solution, but clearly not much better than crashing and introduces a UI inconsistency.

The other approach is to find the offending freed object generated in browser.js and not retained by widget/ that causes the bad click-hold and work back. It may be related to a timer object since the menupopup acts otherwise normally. There is an occasional warning about a leaked timer, but this doesn't seem related since it is never freed. We'll work on this if I am unable to get objc to cough up a freed object (Zombies don't work for some reason; they clash with Mozilla's ObjCException handlers) or the address turns out to be bogus.

If we comment out the line making the menupopup hidden before the setTimeout, then there is no crash. However, the window appears instantly and the back button does not work normally, so this is not a shippable solution.

There is some custom code about hidden menupopups in nsCocoaWindow.mm, but this is not significantly different from 3.6 except for AdjustWindowShadow(); SetUpWindowFilter();

I did add more PPC stuff to the WindowFilter, since I noticed it (this is unnecessary work in CleanUpWindowFilter() as the filter is never applied for PPC on SetUpWindowFilter(). However, this is not the cause as right-click would be going through this same path most likely.

unknown event for PopupWindow, sent to super? (2)

Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x800100f8 0xfffeff40 in objc_msgSend_rtp () (gdb) p/x $r3 $1 = 0x5f41c660 (gdb) x/s $r4 0x90aaedb8 <_errNewVars+382204>: "sendEvent:" (gdb) q The program is running. Exit anyway? (y or n) y % malloc_history 18516 0x5f41c660

(see attached)

If we retain the window in nsCocoaWindow::CreateNativeWindow(), there is no crash. However, we can't release it even in the destructor -- the window has to live longer or it still crashes. I'm a little worried this may leak, so we only retain the window if it is a popup since that appears to be the only place where this matters. The crash is solved.