Comment 17 for bug 1001189

If I run the accessdb command on the 32-bit 12.04 machine it core dumps:

$ /usr/sbin/accessdb /packages/local/share/man/index.db
Segmentation fault (core dumped)

Doing the same on the 64-bit 10.04 machine produces something intelligible:

$ /usr/sbin/accessdb /packages/local/share/man/index.db
$mtime$ -> "1322648132"
$version$ -> "2.4.1"
Data::AMF::Type::NULL~3pm -> "- 3pm 3 1293669463 C Data::AMF::Type::Null - - "
Data::AMF::Type::Null~3pm -> "- 3pm 3 1293669463 A - - - "
NEdit~1 -> "- 1 1 1069626004 C nedit - - "
animate -> "- 1 1 1178029761 A - - - animates an image or image sequence on any X server."
any::moose -> "Any::Moose 3pm 3 1293668769 A - - - use Moose or Mouse modules"
appletviewer -> "- 1 1 1096427362 A - - - Java applet viewer"
attribute::params::validate -> "Attribute::Params::Validate 3pm 3 1293669227 A - - - Validate method/function parameters using attributes"
biosdecode -> "- 8 8 1172493847 A - - - BIOS information decoder"
bonnie++ -> "- 8 8 993754830 A - - - program to test hard drive performance."

As you suspected, the $version$ value is the same 2.4.1
But trying this on a 32-bit 10.04 machine (not normally with this file available) I get something vaguely familiar:

$ /usr/sbin/accessdb /packages/local/share/man/index.db
gdbm fatal: read error

So it seems the underlying issue is the database has no indication (or handling) of 64-bit versus 32-bit data! That seems to me to be a spectacularly dumb omission for anything that performs such an aggressive search for index.db files, as I expect a lot of organisations will have both 32-bit and 64-bit OS in use with networking as well :(