Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 639940

Summary: Crash in gdbmclose.c:46: if (dbf->read_write == GDBM_WRITER)
Product: Red Hat Enterprise Linux 5 Reporter: Michal Nowak <mnowak>
Component: gdbmAssignee: Honza Horak <hhorak>
Status: CLOSED DUPLICATE QA Contact: qe-baseos-daemons
Severity: medium Docs Contact:
Priority: low    
Version: 5.6CC: ohudlick, ovasik
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-03-04 14:27:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
patch of scoredb.c none

Description Michal Nowak 2010-10-04 11:19:11 UTC 
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):

gdbm-1.8.0-26.2.1.x86_64
gdbm-1.8.0-26.2.1.i386

How reproducible:

always

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 Program Management 2011-01-11 20:43:46 UTC 
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 Program Management 2011-01-11 22:35:17 UTC 
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 15:46:57 UTC 
Created attachment 479942 [details]
patch of scoredb.c
Comment 4 Honza Horak 2011-02-21 15:50:03 UTC 
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 16:14:17 UTC 
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 14:27:57 UTC 
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 ***