[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7030:
From: |
Derrell Piper |
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.
- bug#7030:,
Derrell Piper <=
- bug#7030: more info, Jan Djärv, 2011/12/18
- bug#7030: more info, Glenn Morris, 2011/12/18
- bug#7030: more info, Jan Djärv, 2011/12/19
- bug#7030: more info, Stefan Monnier, 2011/12/19
- bug#7030: more info, Jan Djärv, 2011/12/19
- bug#7030: more info, Glenn Morris, 2011/12/19
- bug#7030: more info, David Reitter, 2011/12/19
- bug#7030: more info, Jan D., 2011/12/20
- bug#7030: more info, David Reitter, 2011/12/20