|Summary:||glibc 2.3.2-4.80 breaks PHP gdbm database access|
|Product:||[Retired] Red Hat Linux||Reporter:||Ed Marshall <esm>|
|Component:||glibc||Assignee:||Jakub Jelinek <jakub>|
|Status:||CLOSED WORKSFORME||QA Contact:||Brian Brock <bbrock>|
|Version:||8.0||CC:||drepper, fweimer, mitr|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2004-08-26 04:22:53 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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): glibc-2.3.2-4.80 How reproducible: Always 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 else. 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 similarly.
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) httpd-2.0.40-11 php-4.2.2-8.0.7 gdbm-1.8.0-18 glibc-2.3.2-4.80.3 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.