Really slippery Drupal config bugs and how to root them out

Post-installation seemed as good a place as any -- I'd like to start a thread about how to debug a broken drupal ... because I just broke mine in a wildly intangible way that's driving me nuts.

A first line of defense is usually the devel.module where you can list the db queries, get timing info and page build time; this bug occurs sometime before that because the only db activity I can detect is this very cryptic message in the watchdog (which I have to read via MySQL)

Here's what I have: Half a dozen drupal sites working off the same code, more or less the same mix of modules. One of them times out returning any pages, and watchdog says only

Lost connection to MySQL server during query
query: UPDATE lions_sessions SET uid = 2, hostname = '207.61.5.143', session = 'messages|N;', timestamp = 1097880724 WHERE sid = '454eb49cdf24eca346e849726ae4e22c' in /opt2/home3/teledyn/public_html/includes/database.mysql.inc on line 125.

which probably means nothing.

Ok, so that's the problem, sort of. The only other symptom is that this page times out no matter what page you try to hit, and always only this one db_prefix blog, never the others. At the time it started to fail I was doing trivial edits like setting the secondary menu. it could be a data table corruption but I did do a mysql repair-table on them and got no errors reported.

So I'm stuck with proding this thing by altering PHP code and mucking about in the SQL, and mostly the latter because the other sites work fine and all of them are busy sites I'd rather not pull down.

First stop: the variables.

I figure it has to be a configuration problem, something that got configured or partially configured and now has Drupal tied into a knot. I used the following SQL to compare the variable tables:

select substring(l.name,1,10), substring(l.value,1,20), substring(t.value,1,20) from lions_variable l, teledyn_variable t where l.name = t.name;

but nothing jumps out; using that information, I could set the theme of the errant site to the same theme as the other to rule out theme problems:

update lions_variable set value = 's:11:"unm/teledyn"' where name = 'theme_default';

Not sure if that's all there is to it, but it didn't change the brokeness of the site.

Another tip perhaps, I tried the following to manually insert and configure the devel.module

insert into lions_variable values ('dev_query','s:1:"1";');
insert into lions_variable values ('devel_redirect_page','s:1:"1";');
insert into lions_variable values ('devel_execution','s:1:"5";');
insert into lions_variable values ('dev_timer','s:1:"0";');

unfortunately, the page fails before it does anything, so there's no output from devel.module. Hmmmm ....

Ok, so what's next? I also loaded selected pages into the browser directly just to see if PHP would throw a syntax error; that often finds things, as does adding the following into your .htaccess

   php_value display_errors        1
   php_value error_reporting       "E_ALL & ~E_NOTICE"

Again, this doesn't turn up anything in my situation, but it's been very helpful in the past, especially for finding template or theme errors.

Any other best practices for isolating particularly inscrutable bugs?