A couple tips, troubleshooting a bug in Opera menus

Before I forget and in case I need it later.
A bug in Opera 11.61 I submitted in February [DSK-357462] (that apparently others with similar configurations can not reproduce) still occurs in Opera 11.62. So I looked at other possible causes for that peculiar bug.

The bug is in any menu of Opera, any drop-down list and any right-click menu. When the menus appear, selecting through them is slow at best, and doesn’t apparently work at worse. I can click several times and sometimes forever on an item in the list, it’s as though the state doesn’t change, or takes a while to actually select. I click outside of it to make it disappear and it just stays there until I click either outside of the Opera window, or sometimes (not always) until I hover the mouse over it and then click outside of it, inside the Opera window.

I needed to find when I last performed software updates. Karl gave me this tip:

cat /Library/Receipts/InstallHistory.plist

This is much more accurate than my intuition to search in the console (there is entirely too much info there, and this would take much longer) or looking in the Applications folder and find a common date for “Date Modified”.

This allowed me to check that a few days prior to my noticing the bug, I had performed the “Mac OS X Update Combined” (10.7.3). This was later followed by a “Mac OS X 10.7.3 Supplemental Update”.

Then I needed to assess whether my usage of Opera could be a factor. I typically run it several days or weeks without quitting it. I operate with 1 or more windows and the number of tabs I keep open is around 90. Opera is also my Mail User Agent, has been for years and as such its mail database indexes more than 133K messages (I archived once in 2004, but then I became lazy).

I performed two tests.
The first on my other computer which has the same OS as my work laptop and the same Opera version (the processors are different but I don’t suppose the test is invalid). My opera session on that other computer has an empty mail database and I ran it with one tab. Menus were reactive as expected and selecting through them was smooth and gratifying. I opened several other tabs and I had the same positive experience.
I performed the second test on my work laptop and started a new Opera session with one tab and then a few. I was happy to experience smooth and reactive menu action. Happy and frustrated at the same time.

So maybe there is something in the early February Mac OS 10.7.3 update that impacts Opera to some extent. And if Opera couldn’t reproduce the bug to fix it in 11.62, it may be useful to give them extra info on that bug.

Another good tip, via Dean, was to run in the Terminal:

sample Opera

And perform any menu action for it to dump an “Analysis of sampling Opera (pid xxxxx) every 1 millisecond” in a text file. The blitz sampling, which lasted a fraction of time, analysed me right-clicking on a link in a Web page and clicking on “copy link address”, and wrote 21K lines, hardly any of them making sense to me. I sent it to Opera to accompany my February bug report.

Then I went back to my habitual session, bookmarked for good as many tabs as I could and tried with a 28-tab session. Same frustratingly slow menu actions. Oh well. I need them all (I need more of them in fact) to work, they’re my work flow. I hope this is fixed some day.

Opendirectoryd crashes

I was unlucky enough two months ago to start to experience loss of my (computer) identity, occasionally at wake from sleep. My computer terminal would show “I have no name!” in the prompt instead of my user name, would claim that I am 501, when it should say I’m koalie. Of course, ssh would not want me, telling me to go away as I don’t exist. So I rebooted a couple time and grumbled a lot.Vlad suggested something was wrong with LDAP and my colleague Thomas diagnosed that opendirectoryd was crashing. All true.

It happened again tonight and Vlad found a way to restart opendirectoryd (in Terminal.app):

sudo launchctl
stop com.apple.opendirectoryd

Which restarts opendirectoryd.

I’m none the wiser on what triggers the opendirectoryd crash at wake from sleep. But I’m glad this works when the crash happens.

Update: The above doesn’t always work. Actually, it may have worked just once. Since then, I’ve experienced silent opendirectoryd crash, and no sudo worked, neither some kill -9. Only a restart can fix it.

The mds process was too greedy


Every now and then when my mac is slow, I take a peek in the Activity Monitor, to find out what is the culprit. Today I didn’t find any usual suspect and the only odd bit was the process mds. While it was using barely 10% of the CPU, the memory it used was outrageous. I remember having only 1MB free memory left, and that mds was using 14GB of the virtual memory (this figure stuck, while the real memory one didn’t).

I had learnt that mds is in use for Spotlight indexing. I have no use for Spotlight indexing, because I use other tools or tricks. So I searched for the way to disable Spotlight and did it in the Terminal:

sudo mdutil -a -i off
Password:
/:
 	Indexing disabled.

All of a sudden the process mds jumped from using 14GB of virtual memory to 77MB of virtual memory, whee! And the system memory, of which 1MB was free, reached the comfortable level of 1.7GB, re-whee!

If I ever need Spotlight, the command above is reversed by using “on”.

You’re welcome!

Update of the day after:
It turns out I need that Spotlight indexing after all, if only to search in iCal. <sigh />
mds is on again! until it gets too greedy, that is.

sudo mdutil -a -i on
Password:
/:
 	Indexing enabled.