Does this happen with cli sapi and could you please try this is latest PHP 4.3.0 snapshot. I cannot replicate the crash.

I just tried with the php4-STABLE-200212201630 snapshot  
and the segfault happended again.  This is using the SAPI  
module with mhash support compiled into libphp4.so  
  
Is it possbile i'm compiling mhash wrong?  Compiling mhash  
with:  
./configure --prefix=/usr --enable-shared=no  
 
Should I try with an older version of mhash and any 
suggestions as to what version so try with?

Tried compiling the latest snapshot (12231630) and the 
segfault still occurs with a sightly different backtrace.  
Segfault occurs with both the cli binary and the apache 
module.   
This time I compiled mhash as a loadable module  
(--with-mhash=shared).  
  
Backtrace from Apache module:  
-----------------------------  
Program received signal SIGSEGV, Segmentation fault.  
[Switching to Thread 1024 (LWP 1407)]  
0x401c3f66 in chunk_free (ar_ptr=0x40276fa0, p=0x810e860)  
at malloc.c:3242  
3242    malloc.c: No such file or directory.  
        in malloc.c  
(gdb) bt  
#0  0x401c3f66 in chunk_free (ar_ptr=0x40276fa0,  
p=0x810e860) at malloc.c:3242  
#1  0x401c3d14 in __libc_free (mem=0x810e868) at  
malloc.c:3154  
#2  0x40920cde in zif_mhash (ht=2, return_value=0x8122fcc,  
this_ptr=0x0,  
    return_value_used=1) at  
/tmp/php4-STABLE-200212231630/ext/mhash/mhash.c:185  
#3  0x4072cf4f in execute (op_array=0x811e69c)  
    at  
/tmp/php4-STABLE-200212231630/Zend/zend_execute.c:1596  
#4  0x4071b090 in zend_execute_scripts (type=8,  
retval=0x0, file_count=3)  
    at /tmp/php4-STABLE-200212231630/Zend/zend.c:864  
#5  0x406e373f in php_execute_script  
(primary_file=0xbffff6f0)  
    at /tmp/php4-STABLE-200212231630/main/main.c:1573  
#6  0x40731f2e in apache_php_module_main (r=0x81176d0,  
display_source_mode=0)  
    at  
/tmp/php4-STABLE-200212231630/sapi/apache/sapi_apache.c:55  
#7  0x40732e14 in send_php (r=0x81176d0,  
display_source_mode=0,  
    filename=0x8119038 "/var/www/html/phpcrash.php")  
    at  
/tmp/php4-STABLE-200212231630/sapi/apache/mod_php4.c:556  
#8  0x40732e81 in send_parsed_php (r=0x81176d0)  
    at  
/tmp/php4-STABLE-200212231630/sapi/apache/mod_php4.c:571  
#9  0x080547dd in ap_invoke_handler ()  
#10 0x0806769c in process_request_internal ()  
#11 0x08067713 in ap_process_request ()  
#12 0x0805f867 in child_main ()  
#13 0x0805fa0a in make_child ()  
#14 0x0805fb4d in startup_children ()  
#15 0x080601a0 in standalone_main ()  
#16 0x08060aa3 in main ()  
#17 0x40160589 in __libc_start_main (main=0x8060610  
<main>, argc=3, ubp_av=0xbffffb44,  
    init=0x804f0f4 <_init>, fini=0x80754f0 <_fini>,  
rtld_fini=0x4000b994 <_dl_fini>,  
    stack_end=0xbffffb3c) at  
../sysdeps/generic/libc-start.c:129  
  
--------------------------  
Backtrace from php binary:  
--------------------------  
Program received signal SIGSEGV, Segmentation fault.  
0x402c7f66 in chunk_free (ar_ptr=0x4037afa0, p=0x82275e0)  
at malloc.c:3242  
3242    malloc.c: No such file or directory.  
        in malloc.c  
(gdb) bt  
#0  0x402c7f66 in chunk_free (ar_ptr=0x4037afa0,  
p=0x82275e0) at malloc.c:3242  
#1  0x402c7d14 in __libc_free (mem=0x82275e8) at  
malloc.c:3154  
#2  0x40587341 in mhash_deinit () from  
/usr/lib/php4/mhash.so  
#3  0x40587399 in mhash_end_m () from  
/usr/lib/php4/mhash.so  
#4  0x405873c4 in mhash_end () from /usr/lib/php4/mhash.so  
#5  0x40586c83 in zif_mhash (ht=2, return_value=0x82275cc,  
this_ptr=0x0,  
    return_value_used=1) at  
/tmp/php4-STABLE-200212231630/ext/mhash/mhash.c:180  
#6  0x081753ff in execute (op_array=0x8222f5c)  
    at  
/tmp/php4-STABLE-200212231630/Zend/zend_execute.c:1596  
#7  0x08163540 in zend_execute_scripts (type=8,  
retval=0x0, file_count=3)  
    at /tmp/php4-STABLE-200212231630/Zend/zend.c:864  
#8  0x0812bbef in php_execute_script  
(primary_file=0xbffffa90)  
    at /tmp/php4-STABLE-200212231630/main/main.c:1573  
#9  0x0817b7ca in main (argc=3, argv=0xbffffb34)  
    at  
/tmp/php4-STABLE-200212231630/sapi/cli/php_cli.c:746  
#10 0x40264589 in __libc_start_main (main=0x817ac74  
<main>, argc=3, ubp_av=0xbffffb34,  
    init=0x8062af8 <_init>, fini=0x817bf60 <_fini>,  
rtld_fini=0x4000b994 <_dl_fini>,  
    stack_end=0xbffffb2c) at  
../sysdeps/generic/libc-start.c:129  
  
Using MHASH_SHA1 works though! 
 
Any suggestions?  
  
'make test' also fails two mhash tests - should I send the  
'make test' output as suggested by the script?  
  
The following program compiled against the same mhash  
library works:  
  
int main(void)  
{  
        char *d="password";  
        unsigned char *hd;  
        MHASH td;  
  
  
        td=mhash_init(MHASH_MD5);  
        mhash(td,d,strlen(d));  
        hd=(unsigned char *)mhash_end(td);  
        printf("HASH: %s\n", hd);  
        mhash_free(hd);  
        return(0);  
}

A trace through php shows it loading MD5Final() from   
/usr/lib/libsasl.so.7 when ldap.so is loaded in php.ini   
ahead of mhash.so   
   
Changing the order so mhash.so is loaded before ldap.so   
elminates the crash in the php binary but the module still   
segfaults when running Apache with mod_auth_ldap.   
   
I patched mhash 0.8.17 to prepend "mhash_" to MD5Init,   
MD5Update, MD5Final, and MD5Transform and recompiled PHP   
--with-mhash=shared.   
   
This seems to have cleared up the segfault.  Is there a   
proper fix for this or will the mhash patch be ok?   
   
Hopefully this is redhat-specific.

A symbol clash in two external libraries is not something we can fix, if they're not bundled.

Not a bug in php -> bogus