Bug 86381

Created attachment 91162 [details]
Strace of sample program after using glibc-2.3.2....i386.rpm

I experience the same problem with redhat 9 on ADM Duron; www.kernel.org 2.4.20
+ xfs patches, other that that standard rh9 + updates
(glibc-2.3.2-27.9.i686.rpm)

The problem can be generated by this simple program:
#include <db.h>
									       
						  
int main() {
    DB_ENV *e;
    int ret;
									       
						  
    if((ret = db_env_create(&e, 0)) != 0) {
	e->err(e, ret, "In db_env_create");
    }
    if((ret = e->open(e, "/tmp/m", DB_INIT_LOCK | DB_CREATE | DB_INIT_MPOOL,
0666)) != 0) {
	e->err(e, ret, "In dbenv->open");
    }
									       
						  
}
which gives the following (/tmp/m directory exists):
In dbenv->open: Function not implemented

I traced this problem to the lock initialization phase, more precisely in the
source of db4, file 'mutex/mut_pthread.c', somewhere in function
__db_pthread_mutex_init, but I can't understand why it behaves like that.

While testing with glibc from updates but for i386 (not i686), every program
gives Segmentation fault (I can't even start a new xterm now... :).

The strace right before segv is:
open("/lib/i686/libpthread.so.0", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\200A\0"..., 512) = 512

fstat64(3, {st_mode=S_IFREG|0755, st_size=93268, ...}) = 0
old_mmap(NULL, 325088, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x40208000
old_mmap(0x40215000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xd000) = 0x40215000
old_mmap(0x40218000, 259552, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x40218000
close(3)				= 0
munmap(0x40014000, 78316)		= 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++

So this could be about pthreads and stuff. Using LD_ASSUME_KERNEL=2.2.5 gets
rid of the sisegv, but says: function not implemented.

This looks similar to bug 88178: I think the problem is that DB4 is configured
to use pthread mutexes in Shrike, but this depends on
pthread_mutexattr_setpshared working.  But it seems pthread_mutexattr_setpshared
only works with an NPTL-savvy kernel, so DB4 doesn't work right of booting an
old (or non-NPTL) kernel.

*** Bug 88178 has been marked as a duplicate of this bug. ***

A simple repro case for this is 

  $ rm -rf /tmp/foobar
  $ LD_ASSUME_KERNEL=2.2.5 svnadmin create /tmp/foobar
  svn: Berkeley DB error
  svn: Berkeley DB error while creating environment for filesystem /tmp/foobar/db:
  Function not implemented

Also see bug # 88456.  There is a possible solution mentioned there (a kludgy
workaround in my opinion).

I'm still getting questions from people using my cyrus-imapd rpms on AMD
K6/Athlon CPU's, where it doesn't work. Does anybody at redhat pay attention to
this bug?

Simon, I am not sure if anyone from RedHat is paying any attention to this bug.
 Another bug, #88456, has been open for quite some time which references the
root cause of this problem, and so far I have not gotten anything definite on it
from RedHat.  I am not sure if they are just not paying attention or the issue
is too deep for them to come up with a quick (under 2 month) answer.

BTW, thanks a million in keeping up with the good work with RPM maintenance of
the Cyrus RPMS :)

The root cause of the problem is as above: the db4 package shipped in Shrike only
works correctly when you boot a kernel which has NPTL support, for example the
kernel included in Shrike.  This bug manifests itself when you boot some other
kernel (something which is not really supported).

Actually NPTL support not in the kernel but in glibc.  RedHat seems to have
messed up the glibc pieces pretty well.  Pretty well discussed in bug $ 88456

To Joe Orton,
If I had recompiled my own kernel or glibc, I understand that this was an 
unsupported configuration. But it happens with the kernel and glibc package 
which is installed by the installer. I didn't modify anything. So I still 
consider this a real bug. I reported that AMD K6 CPU's are affected but I got 
reports from other people with Athlon and Pentium I CPU's which are affected 
too. Some of them have now downgraded to RedHat 8.0 but that's not a real 
solution. Is there anything I could try to help resolving the issue?

Well, because nobody seems to really care about this issue, I propose the
following solution until we get an official fix.
Just rebuild db4 with the following .spec file which removes
--enable-posixmutexes. The resulting rpms work fine on any non i686 RedHat 9
installation. YMMV.

http://home.teleport.ch/simix/RPMS/Cyrus-imapd/DB4_for_RH-9/db4.spec

Odd, I have been running cyrus-imapd with RH9' db4 quite happy on an
Athlon server. I have tried to upgrade the kernel to a rawhide kernel
recently and think I ran into this problem. It seemed to me I needed
db4 from rawhide, which required new versions of many things so I
backed off on the kernel. I am planning on upgrading the to Fedora
Core 1 soon and hope I don't run into such issues.

This will be resolved the same way as #91933, hence a duplicate.

*** This bug has been marked as a duplicate of 91933 ***

Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.