Red Hat Bugzilla – Bug 162416
GDBM database dump/restore utility to migrate files between architectures
Last modified: 2015-12-09 12:18:43 EST
Description of problem:
PHP recompiled with GDBM support didin't seem to work on RHEL4 x86_64, and
trying to access the GDBM files by other means seems to fail all the time.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Download and compile dumpgdbm from http://krabulator.free.fr/devel/dumpgdbm.html
2. Run dumpgdbm on a test GDBM file, it segfaults
3. Now compile dumpgdbm on i386, install gdbm.i386, readline.i386 and
libtermcap.i386 (all provided in RHEL4 x86_64), run that dumpgdbm on the same
GDBM file, it works
Access to GDBM files from x86_64 applications doesn't work, from i386 it does.
GDBM file access should work natively from x86_64 applications.
I've also tried installing the latest FC Development x86_64 package, same
result. I also tried with gdbm 1.8.3 (since all RH/FC products are still at
1.8.0) and again, same result.
Some more information on the problem :
- With testgdbm, on a file that works fine on an i386 host :
./testgdbm -g ~/stats.db
gdbm_open failed, File seek error
- Strace of dumpgdbm on that same file :
"lseek(3, 35184372097024, SEEK_SET) = -1 EINVAL (Invalid argument)" (see
the attached strace.txt file)
So it seems to be some kind of file seek error, for whatever that might mean.
Created attachment 116328 [details]
Output from strace dumpgdbm
More digging into the issue :
- Recompile the "testgdbm" program with "make progs" in the gdbm sources.
- On the x86_64 machine, run "testgdbm -g test.gdbm" and insert 2 entries.
- Copy the file over to the i386 machine, run "testgdbm -g test.gdbm", it seems
to work, but the database doesn't contain the inserted entries, it only contains
one empty key/value pair.
The other way around :
Doing the exact same operation but inserting on i386 and trying to read on
x86_64 results in testgdbm's "gdbm_open failed, File seek error" error message.
So it seems that GDBM files created on i386 and x86_64 are incompatible. This is
probably not normal, as endianess is the same, so sompatibility could probably
gdbm databases are, afaik, wordsize specific. Cc'ing Nalin, who I believe looked
at this once.
Unfortunately (for me), you are right. I got this reply from the current
"Of course it works. You're accessing a 32bit GDBM file with a 32bit library.
You can not, however, access a 32bit GDBM file with a *64bit* library.
GDBM files are not portable between different architectures."
So, I guess I could nevertheless change this bug to an RFE, to include some kind
of dump/restore utility that would allow moving GDBM files across architectures?
I'm pretty sure I won't be the last to move GDBM files from i386 to x86_64
The utility that did it for me was gdbmtext :
Which requires the following change to not segfault in some common cases when
--- gdbmtext.c.orig 2005-07-04 17:15:06.963692448 +0200
+++ gdbmtext.c 2005-07-04 19:10:02.505410768 +0200
@@ -71,6 +71,7 @@ indatum (char **ppc)
xbuf = pc;
xbuf = xbuf = 0;
*(wp++) = (char) strtol (xbuf, 0, 16);
+ pc += 2;
*(wp++) = *pc;
Anyone willing to review that gdbmtext.c piece of code and get it included
either in upstream gdbm or at least in the Fedora/RH packages? Some basic
dump/restore functionnality is something really valuable when the format is
binary incompatible across supported architectures...
Changing this to a RFE while I'm at it.
Move to Fedora
Is anyone still interested in providing a gdbm "migration tool"?
User firstname.lastname@example.org's account has been closed
I am new owner of this bug.
I will have a look at the gdbmtext.c and will decide whether we should try to
add this package to the distribution.
(In reply to comment #8)
> Is anyone still interested in providing a gdbm "migration tool"?
Hi , I am facing this kind of problem , but I need a dbm which is not architecture dependent , because I need read on 32 and 64-bit platforms ,
Any suggestion ?
please ask on a public mailing list, only very few people read Bugzilla entries.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Note, that a new gdbm-1.9.1 (already in Rawhide) provides different magic values for 32 and 64 bits, so we can discover what system the file was created on if we use this new version. Even though it is not a solution, I hope it can help at least a bit.
Some weeks ago I found that sqlite3 is a very good alternative and also seems that is platform independent 
Well, sqlite3 might be suitable alternative in some cases, but it is generally very different product.