From: Derrell Piper <ddp@electric-loft.org>
To: 7030@debbugs.gnu.org
Cc: Derrell Piper <ddp@electric-loft.org>
Subject: bug#7030:
Date: Sun, 11 Dec 2011 12:18:53 -0700 [thread overview]
Message-ID: <BBD64346-332C-4EF1-A2AB-E7918E48B32B@electric-loft.org> (raw)
In-Reply-To: <B239F462-D8AF-4A2E-AA98-3816BD2EA033@electric-loft.org>
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.
next prev parent reply other threads:[~2011-12-11 19:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-09-13 19:25 bug#7030: 24.0.50; ns menus are all blank Derrell Piper
2010-09-13 19:34 ` bug#7030: update Derrell Piper
2011-12-11 19:18 ` Derrell Piper [this message]
2011-12-18 14:51 ` bug#7030: more info Jan Djärv
2011-12-19 0:39 ` Glenn Morris
2011-12-19 6:35 ` Jan Djärv
2011-12-19 11:30 ` Stefan Monnier
2011-12-19 16:33 ` Jan Djärv
2011-12-19 19:38 ` Glenn Morris
2011-12-19 23:50 ` David Reitter
2011-12-20 6:49 ` Jan D.
2011-12-20 7:50 ` David Reitter
2011-12-20 23:39 ` bug#7030: seems fixed in trunk Derrell Piper
2011-12-21 6:30 ` Jan Djärv
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BBD64346-332C-4EF1-A2AB-E7918E48B32B@electric-loft.org \
--to=ddp@electric-loft.org \
--cc=7030@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.