Also this will prevent resolution of hostnames in mod_rewrite say you have have that configuration in your apache config and add a rewrite rule of:

RewriteEngine on
RewriteRule ^/magik(.*)         http://www.magik.net$1 [P]

it will hang on the lookup of 'www.magik.net'.  It does not hang, however, if you comment out the line where you load the php module.

Also this will prevent resolution of hostnames in mod_rewrite say you have have that configuration in your apache config and add a rewrite rule of:

RewriteEngine on
RewriteRule ^/magik(.*)         http://www.magik.net$1 [P]

it will hang on the lookup of 'www.magik.net'.  It does not hang, however, if you comment out the line where you load the php module.

reclassified

You should also try the latest CVS versions of both Apache2 and PHP..

Same thing happens with PHP-4.3.0-dev with Apache 2.0.4-dev as of the lastest and greatest from both late last week.  Are you not able to reproduce this?

When apache is compiled with mpm=prefork this bug does not exist.  It does exist when mpm=worker or mpm=threadpool.

-Ryan

So it is clearly an issue of something not being threadsafe somewhere in there.  Perhaps in libgd as you mention that specifically, but who knows.  Thread safety issues like this are very difficult to track down.  There will be hundreds of similar problems which is one of the main reasons that Apache2 in anything but prefork mode and PHP are not going to be a viable production-quality solution for a very very long time.  (read years)

libmysqlclient lib is not the thread-safe?

mysql configure has this option:
--enable-thread-safe-client

btw, that backtrace had some lines about '/prod/mysql/lib/mysql/libmysqlclient.so.10' so you're NOT
using the bundled mysql?

Or to try configure the bundled mysql lib thread-safe:

CFLAGS=-DTHREAD_SAFE_CLIENT ./configure <your options>

Yeah, I read the mysql issue before.  I did however try using the bundled mysql as well as the libmysqlclient_r.  In this particular case '/prod/mysql/lib/mysql/libmysqlclient.so.10' is a symbolic link to the _r library for mysql.  Also things works fine as long as the libgd isn't included as well.

Sorry for the confusion about that.  

Compiled with the most recent option suggestions it still has the same issue and dies in the same place.

CFLAGS=-DTHREAD_SAFE_CLIENT ./configure --prefix=/prod/apache/php --with-apxs2=/prod/apache/bin/apxs --with-mysql --with-gd --without-readline --enable-debug

(gdb) bt
#0  0x402cbbb5 in __sigsuspend (set=0x40acf7fc) at ../sysdeps/unix/sysv/linux/sigsuspend.c:45
#1  0x402901d9 in __pthread_wait_for_restart_signal (self=0x40ad1be0) at pthread.c:969
#2  0x40291a2c in __pthread_lock (lock=0x4001649c, self=0x40ad1be0) at spinlock.c:149
#3  0x4028ed46 in __pthread_mutex_lock (mutex=0x4001648c) at mutex.c:109
#4  0x403b6e50 in _dl_open (file=0x40acfabc "libnss_dns.so.2", mode=1, caller=0x0) at dl-open.c:401
#5  0x403b7ce1 in do_dlopen (ptr=0x40acfa8c) at dl-libc.c:78
#6  0x4000d7c3 in _dl_catch_error (objname=0x40acfa84, errstring=0x40acfa88, operate=0x403b7cc0 <do_dlopen>, args=0x40acfa8c)
    at dl-error.c:152
#7  0x403b7b8c in __libc_dlopen (__name=0x40acfabc "libnss_dns.so.2") at dl-libc.c:42
#8  0x40398eff in __nss_lookup_function (ni=0x80f9ff8, fct_name=0x403cc50e "gethostbyname_r") at nsswitch.c:340
#9  0x40399866 in __nss_lookup (ni=0x40acfb8c, fct_name=0x403cc50e "gethostbyname_r", fctp=0x40acfb90) at nsswitch.c:147
#10 0x4039a80c in __nss_hosts_lookup (ni=0x40acfb8c, fct_name=0x403cc50e "gethostbyname_r", fctp=0x40acfb90) at XXX-lookup.c:70
#11 0x4039c227 in __gethostbyname_r (name=0x81b3308 "reports.estara.com", resbuf=0x403d6ca0, buffer=0x819cc08 "", buflen=1024, 
    result=0x40acfbd0, h_errnop=0x40acfbd4) at ../nss/getXXbyYY_r.c:168
#12 0x4039bbad in gethostbyname (name=0x81b3308 "hostname") at ../nss/getXXbyYY.c:131
#13 0x404806e7 in mysql_real_connect (mysql=0x81b3490, host=0x81b3308 "hostname", user=0x81b3390 "username", 
    passwd=0x81b3410 "password", db=0x0, port=3306, unix_socket=0x0, client_flag=0) at libmysql.c:1307
#14 0x40479e95 in php_mysql_do_connect (ht=3, return_value=0x81b3450, this_ptr=0x0, return_value_used=1, tsrm_ls=0x817d3f0, 
    persistent=0) at php_mysql.c:662
#15 0x4047a1f7 in zif_mysql_connect (ht=3, return_value=0x81b3450, this_ptr=0x0, return_value_used=1, tsrm_ls=0x817d3f0)
    at php_mysql.c:714
#16 0x40433304 in execute (op_array=0x81b0440, tsrm_ls=0x817d3f0) at ./zend_execute.c:1598
#17 0x40445cfd in zend_execute_scripts (type=8, tsrm_ls=0x817d3f0, retval=0x0, file_count=3) at zend.c:810
#18 0x40458fb9 in php_execute_script (primary_file=0x40ad18ac, tsrm_ls=0x817d3f0) at main.c:1381
#19 0x40454575 in php_output_filter (f=0x81aa288, bb=0x81a7f60) at sapi_apache2.c:401
#20 0x08087daf in ap_pass_brigade (next=0x81aa288, bb=0x81aa3b8) at util_filter.c:534
#21 0x0808e06c in default_handler (r=0x8179430) at core.c:3276
#22 0x0807dc62 in ap_run_handler (r=0x8179430) at config.c:193
#23 0x0807e11d in ap_invoke_handler (r=0x8179430) at config.c:373
#24 0x0806cb23 in ap_process_request (r=0x8179430) at http_request.c:257
#25 0x08068d15 in ap_process_http_connection (c=0x8175488) at http_core.c:291
#26 0x08086386 in ap_run_process_connection (c=0x8175488) at connection.c:85
#27 0x0807afca in process_socket (p=0x8175378, sock=0x81753b0, my_child_num=0, my_thread_num=0, bucket_alloc=0x816b190)
    at worker.c:631
#28 0x0807b57d in worker_thread (thd=0x810af58, dummy=0x8168770) at worker.c:945
#29 0x40213644 in dummy_worker (opaque=0x810af58) at thread.c:127
#30 0x4028dc6f in pthread_start_thread (arg=0x40ad1be0) at manager.c:284
#31 0x4028dd5f in pthread_start_thread_event (arg=0x40ad1be0) at manager.c:308

I think rasmus@php.net was pretty on target, I'll take a shot at making libgd in php mt safe and see where that gets me.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".