Dec 11 OSX System Update broke Java, and I had to fix it again

Upgrading from OSX 10.5 Leopard to OSX 10.6 Snow Leopard had some unexpected consequences for the Java installation, basically ditching Java 1.5 and only having Java 1.6. I would think most Java based apps would be fine with an upgrade, but, then again, I’m not a Java man.

I found that Zend Studio had some strange issues when starting up (it didn’t) and the answer was to get the original OSX 10.5 Java 1.5 and put it back where it could be used and do some finagling with settings to let applications use it. It’s all spelled out in this article on how to fix Snow Leopard’s Java Problem

After this past friday’s software update though, it happened again. After a little bit of research and some trial and error, I found out that I had to re-do a part of the previous fix.

Specifically, I had to re-update the symlink for 1.5.0 in /System/Library/Frameworks/JavaVM.framework/Versions so it was pointed at my 1.5.0-leopard folder. I’m not sure if I’ll need to update my other 1.5 related folder to not point to the CurrentJDK.

My /System/Library/Frameworks/JavaVM.framework/Versions directory now looks like this:

1.3        -> 1.3.1
1.4        -> CurrentJDK
1.4.2      -> CurrentJDK
1.5        -> CurrentJDK
1.5.0      -> 1.5.0-leopard
1.6        -> 1.6.0
Current    -> A
CurrentJDK -> 1.6

All of these were updated on Dec 11 when I did the update. So a quick

sudo ln -snf 1.5.0-leopard 1.5.0

And things were good.

Firefox Bookmarks Corruption

I’d noticed that my Firefox bookmarking was acting wonky. When I tried to bookmark a page, the form would pre-populate with an existing bookmark and upon saving, would save a new bookmark with the old bookmark’s information. Not quite what it should have been doing.

Using the built-in bookmark manager was useless since there seemed to be an underlying problem with the SQLite database Firefox uses, so I tried opening up the database using the excellent SQLite Manager Add on for Firefox. By running the PRAGMA integrity_check command I saw that the database disk image is malformed. Uh oh.

It had to be rebuilt.

First, I had to make sure I had a SQLite Command Line Client because I wouldn’t really be able to work on Firefox’s databases from inside Firefox.

Then I navigated over to where my places.sqlite database file inside my Firefox profile (which, for me was ~/Library/Application Support/Firefox/Profiles/{profile_name} )

I ‘connected’ to my SQLite database

sqlite3 places.sqlite

I reran the integrity check to see if I could garner more information

PRAGMA integrity_check;

Which told me some more information that I didn’t know about

On page 11 at right child: 2nd reference to page 1609
rowid 912 missing from index moz_bookmarks_itemlastmodifiedindex
SQL error: database disk image is malformed

I’d read that doing a straightforward dump/reload of the data should fix this sort of problem, so exited out of the SQLite shell and did a dump from SQLite

sqlite3 places.sqlite .dump > places.sql

Followed by load into a new SQLite database

sqlite3 < places.sql

But then I got a bunch of primary key errors

SQL error near line 872: PRIMARY KEY must be unique
SQL error near line 877: PRIMARY KEY must be unique
SQL error near line 883: PRIMARY KEY must be unique
SQL error near line 884: PRIMARY KEY must be unique
SQL error near line 885: PRIMARY KEY must be unique
SQL error near line 888: PRIMARY KEY must be unique
SQL error near line 889: PRIMARY KEY must be unique
SQL error near line 890: PRIMARY KEY must be unique

I popped open places.sql and checked out the lines in question. I saw what appeared to be the primary key which had stopped logically increasing and was sort of random

INSERT INTO "moz_bookmarks" VALUES(915,1,16546,2,110,'Bookmark Page Name #1',NULL,NULL,1256413281706712,1256413281711799);
INSERT INTO "moz_bookmarks" VALUES(29,1,33509,2,135,'Bookmark Page Name #2',NULL,NULL,1258662433785621,NULL);
INSERT INTO "moz_bookmarks" VALUES(28,1,31347,27,0,'Bookmark Page Name #3',NULL,NULL,1258472420957472,NULL);
INSERT INTO "moz_bookmarks" VALUES(27,2,NULL,2,134,'Bookmark Page Name #4',NULL,'',1258472420951405,NULL);

After a cursory glance through the rest of the file, I figured that I could change those primary keys to whatever I wanted as long as they were unique. A quick run through with that, running the same code as before

sqlite3 < places.sql

And success! I renamed my new to replace my old places.sqlite, restarted Firefox and everything worked out hunky dory.

A few notes:

  • Make sure Firefox is completely closed before attempting to do anything with the databases from the command line. You will get errors about the database being locked
  • After restarting Firefox, I did notice issues with my AwesomeBar not quite remembering my usual auto-complete and I also had to click through all of the items in my toolbar in order to get the favicons showing again, but so far nothing major

Timing command line functions

Yet another basic command line tool that is awesome:


This lets you do a quick and dirty profile on some code you’re executing.

Basic Usage

time <command>

This will execute the command and put out a summary detailing how long the command took in total, how long it was tied up in actual execution, and how long it was tied up in system overhead:

real	0m0.031s
user	0m0.004s
sys	0m0.023s

Another nifty function that does one thing and one thing only, but does it well. Thanks Unix philosophy!

Apache, PHP, Snow Leopard and Oracle conspired to kill me, but I didn’t let them!

In a nice epilogue to my post about how Apache, PHP, Zend Debugger and Snow Leopard are conspiring to kill me, I have good news!

Thanks to Zend’s release of a 64-bit version of the Zend Debugger for Mac OSX, I finally got to get everything working together nicely in 64-bit world.

I ended up doing a complete format and re-install of Snow Leopard, since I had too many 32-bit binaries laying around. This gave me a great opportunity to clean up my computer too. Double win!

Along the way, I had a couple of hurdles…

  • iconv continued to throw defined symbol errors. Tried manually compiling iconv in 64-bit but that didn’t work, eventually just went with a Macports install and that worked. Also, tacked “-liconv” to the end of my EXTRA_LIBS in the Makefile. For good measure.
  • Tacked “-lresolv” to the end of EXTRA_LIBS in the Makefile too, thanks to this handy PHP on Snow Leopard reference
  • I used Macports to install the GD related stuff, since the native OSX build of PHP references were broken
  • We use Oracle as a backend at work, and I had gotten the Oracle Instant Client working on my Leopard build but was having a hell of a time getting it working on Snow Leopard.

All of this repeated many times over the past couple of days, trying to get OCI8 to work properly:

  • Downloaded the Instant Client Basic, SDK and SQL*Plus from Oracle
  • Unpacked them all into /opt/oracle/instantclient_10_2
  • Recompiled PHP with “–with-oci8=instantclient,/opt/oracle/instantclient_10_2,10.2″
  • Got lots and lots of “PHP Warning: ocilogon(): OCIEnvNlsCreate() failed. There is something wrong with your system – please check that DYLD_LIBRARY_PATH includes the directory with Oracle Instant Client libraries”
  • Tried setting the environment variables via
    • Bash shell
    • /etc/profile
    • SetEnv in the Apache configs
    • putenv() on the script
    • Voodoo

    But none of it worked.

The problem was that I had made the decision to use the default install of Apache that came with OSX, which has ever so slightly different rules associated with it.

Eventually, I found out about plist files, and how OSX’s Apache ends up caring about them. So a quick addition to /System/Library/LaunchDaemons/org.apache.httpd.plist and an Apache restart later and my DYLD_LIBRARY_PATH woes were over!

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "">
<plist version="1.0">

By adding lines 19 to 25, the environment variables given are passed along to PHP via Apache and eventually the Oracle Instant Client.

Other than the OCI issues, the recompiling of PHP went smoothly. Of course, this is in large part thanks to what I learned on my previous adventures in PHP OSX compilation. I’d still like to know more about .plist files, but for now, I’m happy that I’m back up and running where I need to be.

Apache, PHP, Zend Debugger and Snow Leopard are conspiring to kill me

After an OS upgrade to Snow Leopard, I find myself unable to rebuild PHP.

  • iconv still throws undefined symbol errors. This is no longer fixable by adding -liconv to the EXTRA_LIBS in the Makefile
  • MH_BUNDLE_FLAGS needs to be moved to the end of the group at line 155 otherwise I get more undefined errors
  • After giving up on doing it manually, Macports install of tidy gives a fatal error about lazy symbol binding failing
  • Many of my libraries were built as 32-bit, though this was easy to rectify
  • Even after giving up on iconv and tidy, ZendDebugger is not available for 64-bit on OSX yet. At least, not that I can get to.

That last one is the kicker, since I really enjoy having the debugger so well integrated with Zend Studio 5.5.

So for the time being, it looks like I’ll be staying with the install I’ve got. Unless Zend releases a 64-bit version for OSX, my next step will be to figure out how to compile as 32-bit so I can retain control over my install.

Entirely too many hours spent on getting this to work, and I end up using Time Machine to restore my old install. Hooray for frequent backups though. Otherwise I’d have had to recompile all of my old libraries as 32-bit. And that would have been the end of me.

Update: Success!

Web Safe Fonts

Windows fonts / Mac fonts / Font family
Arial, Arial, Helvetica, sans-serif
Arial Black, Arial Black, Gadget, sans-serif
Comic Sans MS, Comic Sans MS, cursive
Courier New, Courier New, Courier, monospace
Georgia, Georgia, serif
Impact, Impact, Charcoal, sans-serif
Lucida Console, Monaco, monospace
Lucida Sans Unicode, Lucida Grande, sans-serif
Palatino Linotype, Book Antiqua, Palatino, serif
Tahoma, Geneva, sans-serif
Times New Roman, Times, serif
Trebuchet MS, Helvetica, sans-serif
Verdana, Verdana, Geneva, sans-serif
Symbol, Symbol (Symbol, Symbol)
Webdings, Webdings (Webdings, Webdings)
Wingdings, Zapf Dingbats (Wingdings, Zapf Dingbats)
MS Sans Serif, Geneva, sans-serif
MS Serif, New York, serif

Lifted from

Git and SVN Notes

More for my own reference than anything else…

I have an SVN repository cloned locally. I’ve made a couple of changes in order for my application to run locally and I committed those all against the “dev” branch I set up.

I then go off and do some actual work, which then needs to get sent back upstream to SVN. This is my workflow.

Starting in the dev branch, with all of my changes committed…

  1. Because I should be making sure I have the newest stuff from SVN, just in case
    git svn rebase
  2. Switch over to the master, which should mimic SVN
    git checkout master
  3. Bring master up to date with the dev branch
    git rebase dev
  4. Remove the commits I don’t want to push back to SVN
    git rebase -i git-svn
  5. Because I’m paranoid and want to make sure only the commits I want are actually coming through
    git svn dcommit --dry-run
  6. Commit it off to SVN
    git svn dcommit

Changing History

Revise the last 37 commits. Opens up a log in $EDITOR where you can ‘squash’ commits together
git rebase -i HEAD~37

Undoing crazy rebases

  1. Find the commit you want to bring back, copy it’s sha1 starter
    git reflog
  2. Boom, commit is back.
    git cherry-pick <sha1 starter></sha1>
  • About

    Tom Sartain is a PHP developer, photographer, and overall information junkie. As a diploma-bearing philosopher, he does what 99% of all philosophy majors do after graduation: something else.