A nice change from the place where I am now (and have been the last 13 years), where the manglement in their infinite witlessness have decided that we should drop everything we have developed in perl and change to
The decision was taken nearly 2 years ago, and since then development and maintainance of our production perl-systems has been trottled down to nearly nothing - much to the annoyance of the users who are happy with th systems and want more.
Tool and architecture decisions have been totally lacking - in fact nothing has happened - except that all developers got a 3 day
Just after my holidays I stumbled across an add from Adapt, where one of the Copenhagen Perl Mongers works. I applied and got the job.
I'm looking forward to it sooo much
We have a number of Alphas running Tru64 (about 20) and our home directory is NFS-mounted on all the machines (so you have your files with you everywhere).
The web-development Alphas have just beeen upgraded from Tru64 v4.0G to v5.1B - the server people did a clean install, so as to remove any lint collected over the years.
I had sync'ed
Everthing was OK.
The machines were released to the users and everyone seemed happy until the guy on the table next to me said that his Apache::ASP setup acted strangely, it crashed whenever he fiddled with the $Session-variable in his scripts.
"Hmmm...." I said. "I'll have a look at that". Famous last words.
The apache server crashed with a segmentation violation deep down inside Apache::ASP's internals - I finally tracked it down to a call to DB_File.
"No problem - I'll just upgrade DB_File" I thought - perhaps something has broken in the upgrade - so a recompilation might be called for.
Download the latest DB_File, and do Perl Makefile.PL, make test and boom DB_File fails in its tests.
Wierd - DB_File shouldn't SEGV.
Check rt.cpan.org for known bugs: I found one, where someone reported that the version of the underlying BerkeleyDB delivered with Tru64 v5.1B had a bug.
Download the latest berkeleyDB, compile and install. Retest DB_File: still boom.
Now I'm getting desperate. One of out test-machines runs the same Apache::ASP application as originally gave the error, so I looked there and everything semed ok - it was at a lower patchlevel than the dev.box but otherwise the same.
I tested DB_File on that: boom, hmmmm....
I looked in the DB_File code, and it seems that it sends a wrong argument to the db_del function - deep down in a macro in an XS-file. I wanted to make a small test-case, so that I could see if that was the error. So I headed back to BerkeleyDB, and looked for example code.
A the README passed over my screen something about 'NFS' caught my eye.
* To run the test harness for this module, you must make sure that the directory where you have untarred this module is NOT a network drive, e.g. NFS or AFS.
I was doing all this in my 'work' subdirectory to my home - which is NFS mounted!
Move over to
It seems that Tru64 v4.0G had an undocumented feature that allowed BerkeleyDB files to be on an NFS-mounted filesystem. This feature has been removed in v5.1B.
Once again the lesson is: when debugging, take your time. Check every step, and do read the READMEs - don't assume that you can remember it from last you installed, things may have changed.
The fix was to move Apache::ASP's session-state files away from the home directory tree to somewhere in
The boys already like it, and we wast^Wenjoyed over 3 hours yesterday.
I blame Geoff! (updated, thx Scott)