Bug 159006

Summary:	Pervasive PSQL v9 does not work with glibc-2.3.5/gcc-4.0
Product:	[Fedora] Fedora	Reporter:	Derek P. Moore <derek.p.moore>
Component:	glibc	Assignee:	Jakub Jelinek <jakub>
Status:	CLOSED NOTABUG	QA Contact:	Brian Brock <bbrock>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-06-01 17:17:29 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:

Description Derek P. Moore 2005-05-27 15:56:25 UTC

With Pervasive PSQL v9, mkded (Btrieve's Micro-Kernel Data Engine Daemon) seems
to start up just fine, but it doesn't seem to be able to communicate with client
applications to open and manipulate Btrieve data files.

mkded uses shared memory to communicate with client applications.  The client
application tells mkded what files to open and what operations to perform (via
the Btrieve API), and mkded does all the low-level work of read and writing the
data files for the client app.

Background:

We're porting some retail pharmacy management software from SCO OpenServer 5 and
Btrieve 4.11 to Linux and Pervasive PSQL v9.  This is our first step to phasing
out this 20+-year-old application as we embark upon developing a new enterprise
system to replace the old school C code that has been evolving for decades.

We have our codebase cross-compiling on SCO and Linux.  The codebase works with
Btrieve 4.11 on SCO, and it also works with PSQL 9 on SUSE 9.2.  I'm testing the
code on Rawhide and fc4test3 because of the benefits of gcc-4.0.  Our
application compiles and links just fine, but it can't seem to contact mkded via
shared memory.

I don't get any obvious errors or crashes like the guy who was trying to work
with PSQL 8, I just can't get the client to communicate with mkded.

+++ This bug was initially created as a clone of Bug #124770 +++

Description of problem:

Pervasive. SQL Server v.8 does not work with glibc-2.3.2-101,2.3.3-
27,2.3.3.-30. Only with glibc-2.3.2-101.4. Checked in Fedora Core1 
and Core2. After restart PSQL - " May 29 17:37:51 srv mkded: 
MKDE0820: Shared memory allocation failed. Server or one of its 
components may be already running "  

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

glibc-2.3.3-27

Comment 1 Jakub Jelinek 2005-05-27 16:12:00 UTC

As this application is not included in Fedora nor RHEL, you need to first
provide it is a glibc or gcc bug and if it is, create a small self-contained
testcase that reproduces it.
Start with e.g. trying to build it with a different compiler (FC4 e.g. includes
gcc 3.2.3-RH as compatibility compiler), different compiler options.
If that makes it work, do a binary search to find out which exact file and
routine the problem happens in, then create a self-contained testcase with
that routine so that it can be analyzed by us.
If it is not compiler related and e.g. it worked with older glibc and does not
with the FC4 one, again, debug where the behaviour differs, create a
self-contained testcase that shows that.

Comment 2 Derek P. Moore 2005-06-01 17:17:29 UTC

I apologize, but I submitted this bug in error.  It's not a bug after all.  My
problem was a rather obscure installation/configuration issue.  Apparently mkded
can be picky about permissions.

mkded runs as user psql, and the client application works fine when its
executable is setuid psql.  On a few of our other development boxes, we've not
run into this permissions pickiness...  So I guess we're still trying to figure
out why it's extra picky on my box.