Bug 639940 - Crash in gdbmclose.c:46: if (dbf->read_write == GDBM_WRITER)
Crash in gdbmclose.c:46: if (dbf->read_write == GDBM_WRITER)
Status: CLOSED DUPLICATE of bug 477300
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gdbm (Show other bugs)
All Linux
low Severity medium
: rc
: ---
Assigned To: Honza Horak
Depends On:
  Show dependency treegraph
Reported: 2010-10-04 07:19 EDT by Michal Nowak
Modified: 2013-03-07 21:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-03-04 09:27:57 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
patch of scoredb.c (671 bytes, patch)
2011-02-21 10:46 EST, Honza Horak
no flags Details | Diff

  None (edit)
Description Michal Nowak 2010-10-04 07:19:11 EDT
Description of problem:

I tried to run this example http://www.cs.mun.ca/~rod/Fall97/cs3718/Examples/Gdbm/ on RHEL5.6 pre-alpha and it crashed in libgdbm.so.2:

.qa.[root@x86-64-5s-m1 ~]# gcc -lgdbm scoredb.c -o scoredb -g

.qa.[root@x86-64-5s-m1 ~]# gdb ./scoredb 
(gdb) r
Starting program: /root/scoredb 

Program received signal SIGSEGV, Segmentation fault.
gdbm_close (dbf=0x0) at gdbmclose.c:46
46	  if (dbf->read_write == GDBM_WRITER)
(gdb) bt
#0  gdbm_close (dbf=0x0) at gdbmclose.c:46
#1  0x0000000000400bea in sdbFree (db=0x602010) at scoredb.c:123
#2  0x0000000000400c90 in main () at scoredb.c:143

I am not certain this test case is valid but we have it in Beaker test case /CoreOS/gdbm/Sanity/Build-and-link-app-with-gdbm which apparently works nice on RHEL6.

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


How reproducible:


Additional info:

You can see in Beaker job it fails on all archs https://beaker.engineering.redhat.com/jobs/21553. We use to run this test in bug 581524 (rhel6.0) verification but I think there's nothing related to this particular test case re that bug, but may be worth knowing.
Comment 1 RHEL Product and Program Management 2011-01-11 15:43:46 EST
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 2 RHEL Product and Program Management 2011-01-11 17:35:17 EST
This request was erroneously denied for the current release of
Red Hat Enterprise Linux.  The error has been fixed and this
request has been re-proposed for the current release.
Comment 3 Honza Horak 2011-02-21 10:46:57 EST
Created attachment 479942 [details]
patch of scoredb.c
Comment 4 Honza Horak 2011-02-21 10:50:03 EST
Firstly, I would say there should be a simple check of return value from gdbm_open in function sdbCreate (scoredb.c) after:

  73: if (!(db->rd = gdbm_open(...))) ...

which would end the example with error code instead of Segmentation fault error, but this is just a cosmetic correction. 

The problem itself is located in gdbm-1.8.0, which doesn't work well with flock (fnctl works well). 

The bug is fixed in package gdbm-1.8.3 (it uses fnctl instead of flock) in Rawhide, but not in RHEL 5 (it is already tracked in bug #477300).

However, there is a solution how to make the example to work. We need to open files with GDBM_NOLOCK option, so the flags should be GDBM_WRCREAT | GDBM_NOLOCK and GDBM_READER | GDBM_NOLOCK. 

For details see the patch above.

Will this solve your problem?
Comment 5 Michal Nowak 2011-02-21 11:14:17 EST
what's worth is to clone scoredb.c to scoredb-patched.c and have two runs, first which exploits the problem in gdbm, second which permits scoredb binary execution. But low priority, perhaps when gdbm has erratum in RHEL5.
Comment 6 Honza Horak 2011-03-04 09:27:57 EST
Since this bug has the same reason as bug #477300, I'm closing this one as a duplicate.

*** This bug has been marked as a duplicate of bug 477300 ***

Note You need to log in before you can comment on or make changes to this bug.