Bug 86449 - glibc 2.3.2-4.80 breaks PHP gdbm database access
Summary: glibc 2.3.2-4.80 breaks PHP gdbm database access
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: glibc
Version: 8.0
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-03-22 06:11 UTC by Ed Marshall
Modified: 2016-11-24 15:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2004-08-26 04:22:53 UTC

Attachments (Terms of Use)

Description Ed Marshall 2003-03-22 06:11:44 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20030221

Description of problem:
Upon upgrading to glibc 2.3.2-4.80, an installed instance of phpwiki using gdbm
as it's storage mechanism stopped working. Trying a different storage method
(db2, db3, etc) worked fine, but was an unusable solution because the data (in
gdbm format) is the whole reason the wiki exists. ;-) Rolling back to the
previous release of glibc fixed the problem.

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

How reproducible:

Steps to Reproduce:
1. Create a phpwiki (phpwiki.sf.net) instance using gdbm.
2. Initialize the database by visiting it once.
3. Upgrade glibc.
4. Visit phpwiki instance.

Actual Results:  "database driver failed to initialize"

Expected Results:  "Welcome to PHPWiki" ;-)

Additional info:

Looks like this is just one of a rash of bugs triggered by this glibc update, if
bugzilla is any indication.

Comment 1 Jakub Jelinek 2003-03-26 17:48:12 UTC
Can you please try ftp://people.redhat.com/jakub/glibc/errata/8.0/ ?

Comment 2 Ed Marshall 2003-03-27 15:28:44 UTC
Sorry, this one didn't do it, although I appreciate the change to restart sshd.
;-) I get the same results as last time; a rollback to 2.2.x fixes the problem.
I wish there was a way to get a little more information out of PHP than "driver
initialization failed". :-P

I got a chance to do a little more digging while I was writing this response.
I've tried doing basic tests of linking against gdbm (simple
gdbm_open/insert/close() stuff), and they're working fine; it's PHP's usage of
it that seems to be causing issues. I've tried, but have so far been unable to
build a small test case; dba_xxx() all seem to work as expected with a gdbm
database. The only way I've been able to produce that specific error is to
create a database with dba_open(..."c"...), then chmod it such that PHP can't
write to it (ie. root:root:0644), and then try opening it for writing (ie. mode
"w", "c", or "n"), which isn't the case with the live site (apache:apache:0644,
parent directory is readable). My best guess: something wacky is causing
gdbm_open() to either fail under the hood, or return something (or call
gdbm_open's fatal_func) that PHP can't deal with.

I'm sure something weird is going on in phpwiki, but I go crosseyed every time I
look at that code. :-P

Hope some of this digging helps. Let me know if you want me to look at anything

Specific version information, if it helps:

- php-4.2.2-8.0.7
- gdbm-1.8.0-18
- an older CVS version of phpwiki, although current CVS produces the same
result, and I'd be very surprised to see the released version not behaving

Comment 3 Jakub Jelinek 2003-03-29 08:47:53 UTC
Can you please try ftp://people.redhat.com/jakub/glibc/errata/8.0/*4.80.3* ?
There were apparently more things to get /lib/i686 used on buggy kernels again.

Comment 4 Ed Marshall 2003-03-29 17:43:05 UTC
Yep, that did it. Thanks, Jakub!

Comment 5 Ed Marshall 2003-03-31 01:38:40 UTC
Gack. Sorry, that fixed it for my system, but I have a client with the same
software that is bumping into the exact same problem. :-P Specifics:

Non-SMP i686: Intel PIII 730MHz (My sytem was SMP, if that makes a difference)

I don't have regular access to the system in question, and it's being used as a
helpdesk application during business hours, so I've had to back out the glibc
update and go back to 2.2. Let me know if you need another revision tested out,
and I'll try a remote after-hours upgrade for them.

Comment 6 Andrew Shearwood 2003-04-12 23:48:44 UTC
Hi folks.

I'm having problems with this package too. I've tried the files in that ftp
link, but it just complains that "A newer version is already installed"

System Specs:
Red Hat 9
AMD Athlon 800
PHP 4.3.1 (manual configuration as 4.2.2 has security holes and hasn't been
updated yet)
Apache 2

Comment 7 Ed Marshall 2003-04-30 19:49:04 UTC
More to note: the official errata release (glibc-2.3.2-4.80.6) is unusable on
any system I've tried it on running phpwiki. And, because I've "lost" (read:
prematurely deleted) my copy of 2.3.2-4.80.3, I've had to revert the one working
system I had back to 2.2 as well. ;-P

Comment 8 Ulrich Drepper 2003-11-05 19:33:27 UTC
All these random bugs point squarely at a bug in the application.  Did
somebody try more recent versions and debugged the code?  Look at the
way the code uses glibc interfaces?  The only changes we deliberately
make are those not effecting the user API or those fixing bugs.  If
the ocde uses undocumented functionality or relies on bugs, it is out
of luck.

Please update this bug with more current information.  So far I see no
reason to spend much time to debug a 3rd party app.

Comment 9 Ulrich Drepper 2003-11-20 17:26:45 UTC
Ping.  Can somebody make some up-to-date observation?  Otherwise I'll
assume this is no problem at all.

Comment 10 Ed Marshall 2003-11-20 18:37:15 UTC
Unfortunately, I can no longer test this. :-P I managed to migrate
both Wiki instances to bdb instead of gdbm, because it was just safer
that way. I suspect this is a problem with the way PHP loads
libraries, but I no longer have a live test case available. The
instructions I provided originally should still work, however, if you
really want to try tracking this down.

Comment 11 Ulrich Drepper 2004-08-26 04:22:53 UTC
Not necessary to work on this.  I doubt there has been a problem and
even if, that release is far too old.

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