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): gdbm-1.8.0-24.x86_64 How reproducible: Always. 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 Actual results: Access to GDBM files from x86_64 applications doesn't work, from i386 it does. Expected results: GDBM file access should work natively from x86_64 applications. Additional info: 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 be achieved.
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 maintainer : "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 servers... The utility that did it for me was gdbmtext : http://starynkevitch.net/Basile/gdbmtext.c Which requires the following change to not segfault in some common cases when importing : --- 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[1] = pc[2]; xbuf[2] = xbuf[3] = 0; *(wp++) = (char) strtol (xbuf, 0, 16); + pc += 2; } else *(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 pnasrat's account has been closed
Hi, 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. Cheers Ondrej
(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 ? Thanks,
Hi Sergio, 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 [1] [1] http://stackoverflow.com/questions/15024658/are-sqlite3-databases-are-platform-independent
Well, sqlite3 might be suitable alternative in some cases, but it is generally very different product.
Gdbm in latest versions contains gdbm_dump (and gdbmexport) tool which allows exporting of database to Flat Format (see gdbm doc). Also it is possible to install gdbm.i686 on 64-bit systems to support reading of gdbm databases created without largefiles support. Feel free to reopen. Or for new features create bugs in upstream tracker - https://puszcza.gnu.org.ua/bugs/?group=gdbm