Bug 86449

Can you please try ftp://people.redhat.com/jakub/glibc/errata/8.0/ ?

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.

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.

Yep, that did it. Thanks, Jakub!

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.

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

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

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.

Ping.  Can somebody make some up-to-date observation?  Otherwise I'll
assume this is no problem at all.

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.

Not necessary to work on this.  I doubt there has been a problem and
even if, that release is far too old.