bug-gnu-emacs
[Top][All Lists]
Advanced

[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.











reply via email to

[Prev in Thread] Current Thread [Next in Thread]