Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

whoops, should be feedback.

I just re-tried with php4-STABLE-latest.tar, which is:  php4-STABLE-200308111730.
I got the same result, and the same output from gdb:

---------------
(gdb) run -X
Starting program: /disk1/apache/./bin/httpd -X
[New LWP 1]
[New LWP 2]
[New LWP 3]
[New LWP 4]

Program received signal SIGSEGV, Segmentation fault.
0xff1b319c in strlen () from /usr/lib/libc.so.1
(gdb) bt
#0  0xff1b319c in strlen () from /usr/lib/libc.so.1
#1  0xfe6d8eac in add_property_string_ex (arg=0x3fe530, key=0xfe72e8f8 "def", key_len=4, str=0xb <Address 0xb out of bounds>, duplicate=1)
    at /disk2/source/php/releases/php4-STABLE-200308111730/Zend/zend_API.c:978
#2  0xfe55d2f8 in zif_mysql_fetch_field (ht=2, return_value=0x3fe530, this_ptr=0x0, return_value_used=1)
    at /disk2/source/php/releases/php4-STABLE-200308111730/ext/mysql/php_mysql.c:2165
#3  0xfe6efd64 in execute (op_array=0x2e8bb8) at /disk2/source/php/releases/php4-STABLE-200308111730/Zend/zend_execute.c:1616
#4  0xfe6f009c in execute (op_array=0x2e9f40) at /disk2/source/php/releases/php4-STABLE-200308111730/Zend/zend_execute.c:1660
#5  0xfe6f009c in execute (op_array=0x25b558) at /disk2/source/php/releases/php4-STABLE-200308111730/Zend/zend_execute.c:1660
#6  0xfe6f009c in execute (op_array=0x2ea038) at /disk2/source/php/releases/php4-STABLE-200308111730/Zend/zend_execute.c:1660
#7  0xfe6f009c in execute (op_array=0x3e0348) at /disk2/source/php/releases/php4-STABLE-200308111730/Zend/zend_execute.c:1660
#8  0xfe6f2bd4 in execute (op_array=0x15b060) at /disk2/source/php/releases/php4-STABLE-200308111730/Zend/zend_execute.c:2181
#9  0xfe6f009c in execute (op_array=0x130358) at /disk2/source/php/releases/php4-STABLE-200308111730/Zend/zend_execute.c:1660
#10 0xfe6d4bcc in zend_execute_scripts (type=8, retval=0x0, file_count=3)
    at /disk2/source/php/releases/php4-STABLE-200308111730/Zend/zend.c:885
#11 0xfe67850c in php_execute_script (primary_file=0xffbef478) at /disk2/source/php/releases/php4-STABLE-200308111730/main/main.c:1721
#12 0xfe6f6df4 in apache_php_module_main (r=0x125e18, display_source_mode=0)
    at /disk2/source/php/releases/php4-STABLE-200308111730/sapi/apache/sapi_apache.c:54
#13 0xfe6f8630 in send_php (r=0x125e18, display_source_mode=0, filename=0x126938 "/disk1/wwwdev/htdocs/PostNuke-0.726/html/index.php")
    at /disk2/source/php/releases/php4-STABLE-200308111730/sapi/apache/mod_php4.c:620
#14 0xfe6f86a8 in send_parsed_php (r=0x125e18) at /disk2/source/php/releases/php4-STABLE-200308111730/sapi/apache/mod_php4.c:635
#15 0x420a8 in ap_invoke_handler ()
#16 0x61a18 in process_request_internal ()
#17 0x61a9c in ap_process_request ()
#18 0x54568 in child_main ()
#19 0x547fc in make_child ()
#20 0x54a18 in startup_children ()
#21 0x554dc in standalone_main ()
#22 0x56138 in main ()
---------------

Any more suggestions?

thanks!

Can you please nuke one variable from this equation and remove --with-mnogosearch from your configure line for PHP?

Do this before reconfigure:
# rm config.cache 

Could you please try to isolate the query which causes this problem and if possible make small script that can be used to replicate the problem.

removing mnogo from the configure worked.  (I put it back one more time to be sure, then removed it again).  

FYI:  I was using mnoGoSearch-3.1.21, which is listed as the "Stable" release.

Not sure why it broke, since I haven't used it's functionality yet, and was testing an entirely different application.  Maybe it replaces some other core function?

Can you say if this has any implications for mnogo support?

thanks again!

Iliaa, I would love to help, but the problem showed itself in a 3rd-party php application (post-nuke) that I am examining for the 1st time and am not familiar with at all.  So I am not sure where to even begin to isolate the problem.  
If you have any suggestions, I would be happy to work with you to find the source of this.  But as of now, I am kinda lost as to why 'mnogo' is crashing 'postnuke', and the crashes don't give me any clear info on what function is being executed so that I could even search for a telltale string.

As I said, I would be happy to assist if you could give me a starting place.

thanks for the quick responses!

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. 

Thank you for your interest in PHP.

This is an entirely mnoGoSearch-3.1.21 bug. The library performs a number of conditional operations on uninitialized values that will result in undefined behaviour and possible memory corruptions. I've tried the   3.2.14 development release but it failed to compile on my system, maybe it will on yours :).