Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
First Last Prev Next    This bug is not in your last search results.
Bug 63980 - reproduceable gdbm fatal read error
reproduceable gdbm fatal read error
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gdbm (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Trond Eivind Glomsrxd
Aaron Brown
http://www.sourcelight.com/open/break...
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2002-04-22 20:20 EDT by Need Real Name
Modified: 2007-04-18 12:42 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-25 17:52:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
program to break gdbm (251.73 KB, application/octet-stream)
2002-04-22 20:21 EDT, Need Real Name 		no flags Details
Patch I received from gdbm maintainer (2.96 KB, patch)
2002-04-25 17:41 EDT, Need Real Name 		no flags Details | Diff
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Need Real Name 2002-04-22 20:20:40 EDT 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc1) Gecko/20020417

Description of problem:
I think I've located a reproduceable gdbm bug under linux.  It happens when a
specific set of items are inserted into a database from scratch.  I get a
gdbm fatal read error.  From cursory glancing over the source it looks to me
like gdbm is seeking to the end of the file and then getting a short read
while looking for an empty "bucket."

I've included a URL for a tar file with an example program and text file of keys
and value lengths to insert.  Please read the README for specific instructions.

A couple of notes:

1. This ONLY happens on 64 bit builds of this (i.e. -D_FILE_OFFSET_BITS=64).
2. This has been verified on redhat 6.2, 7.1 and 7.2 systems.

Version-Release number of selected component (if applicable): 1.8.0

How reproducible:
Always

Steps to Reproduce:
Download and unpack the following file...

http://www.sourcelight.com/open/breakgdbm.tar.gz

Read the README for specific instructions, but the general idea is that you need
to build a 64 bit version of the library and then link the breakgdbm.c program
against it.  The program should be run with the keys.txt file as it's input. 

Again, the README in the archive has specific instructions.

Actual Results:  gdbm fatal: read error

Expected Results:  build a database.

Additional info:
Comment 1 Need Real Name 2002-04-22 20:21:53 EDT 
Created attachment 54944 [details]
program to break gdbm
Comment 2 Trond Eivind Glomsrxd 2002-04-25 17:29:40 EDT 
We don't build it that way, and this is a major reason why...
Comment 3 Need Real Name 2002-04-25 17:41:28 EDT 
Created attachment 55368 [details]
Patch I received from gdbm maintainer
Comment 4 Need Real Name 2002-04-25 17:44:37 EDT 
Do you mean you don't build it as an archive file or you don't build it using
the 64 bit offsets.

I've attached a patch I got from the gdbm maintainer (downsj@downsj.com). 
Everything looks ok now, but considering how rare this was, it's hard to verify.
Comment 5 Trond Eivind Glomsrxd 2002-04-25 17:52:42 EDT 
We don't build gdbm with 64 bit offsets (may change). Unfortunately, gdbm has
been rather stagnant for a long time, while bdb is alive and well. I'll take a
look at the patch and will probably put it in.
Comment 6 Trond Eivind Glomsrxd 2002-04-25 18:45:17 EDT 
Added the patch and 64 bit directive to gdbm-1.8.0-15
Comment 7 Need Real Name 2002-04-25 19:12:22 EDT 
You are probably aware of this, but there is no binary compatiblity between 32
and 64 bit gdbm databases.
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.