GNU bug report logs - #7030
24.0.50; ns menus are all blank

Previous Next

Full log

Message #13 received at 7030 <at> debbugs.gnu.org (full text, mbox):

From: Derrell Piper <ddp <at> electric-loft.org>
To: 7030 <at> debbugs.gnu.org
Cc: Derrell Piper <ddp <at> electric-loft.org>
Subject: bug#7030
Date: Sun, 11 Dec 2011 12:18:53 -0700

More information...  I ultimately gave up trying to debug this because I've been living overseas and don't have sufficient bandwidth to download XCode.

This first came to light concurrent with upgrading to Snow Leopard (10.6), which happened when I upgraded my MacBook Air hardware.  This didn't seem to happen prior to 10.6 and FWIW, I was a beta tester of Adrian's nextstep branch prior to it getting checked into the GNU Emacs trunk.

I've lived with this problem for the last year and a half and finally have a little while to debug it some more.  First, I'm now on 10.7.2 on a MacBook Air (late 2010) w/ 4G and 256G SSD.  The problem is not related to my .emacs initialization file or any per-user or per-system customization, as far as I can determine from using DTrace 'opensnoop' and nulling everything out.  It does, however, seem to be related to my personal OS X environment, somehow.

I run a number of items at Login:

	Speach Events
	SpeachSynthesisServer
	Livescribe AutoLaunch
	Livescribe Connect AutoLaunch
	CoverSutra (2.2.2, pre-AppStore)			http://sophiestication.com/coversutra/
	iTunes
	FFHelperApp (2.2)						http://kevingessner.com/software/functionflip/
	Radium (2.8.3, pre-AppStore)				http://www.catpigstudios.com/

Observations:

1) if I create a new unprivileged test account and run Emacs out of there, it works
2) if I remove FFHelperApp (FunctionFlip.prefPane) *and* Radium from my Login items, it works
3) if I add Radium to the test account Login items, it works there
4) if I also add FunctionFlip.prefPane to the test account Login Items, it works there
5) if I put either Radium or FunctionFlip.prefPane back on my account, it fails when the Login Items fire; until then, it works
6) when it does fail, the Application and Help menus are always valid (possibly because they're baked into main application NIB?)
7) this happens on 23.n as well as the latest 24 nightly -- 24.0.92.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2011-12-02 on bob.porkrind.org
8) it works under Aquamacs (which is based on the same nextstep code), even with Radium and FunctionFlip present

I have been running without Radium and FunctionFlip for the last 24 hours or so and it has not failed since.

Thoughts:

I believe there was some controversy about inserting items into the OS X menu bar, circa Leopard or so, but it's a hard to Google this because of the noise using "crack" as a search term.  I could believe that FunctionFlip and Radium possibly share the same inherently buggy menu cracker, which is perhaps triggering a bug in how the dynamic menu code is functioning.  It's almost like it's a caching problem when it's happening because once you get the menu to drop, it's there for "a while."  In fact, if you keep flailing on a menu or two, even when Radium comes up, the menus you're flailing on often stay valid, while the others that you're ignoring go blank.  Or perhaps, the nextstep code simply has always had a day one bug that's just happening more often since 10.6.  A Google search for "emacs blank menus os x" shows that I'm not alone in seeing this problem, see also 8249 & 9206.

Wish I could be more help.  I might try doing some forensic analysis on Radium and FunctionFlip and see if I can find anything in common in their binaries.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.