Hi, Thank you all for your response. But turns out that the problem I am facing is caused by something else and unrelated to MPMs being threaded. The test case details gave me a clue. The test was trying to load mod_php between graceful restarts, i.e start apache without mod_php, then modify the config file to load it and do a graceful restart. This clearly fails because mod_php loads only on the second load within apache. It does this by setting some pool user data in the beginning of sapi_apache2.c:php_apache_server_startup(). So I'd have to do two graceful restarts for it to take effect. Now, I want to know if I can comment out this piece of code where it checks/sets the user data and make it load every time. This will help me enable the module between restarts too. Will this break something ? Do I need to post this query on a different mailing list to get a response from the PHP dev team ? Rgds, Rashmi On Dec 14, 2007 10:34 PM, Richard Lynch <ceo@xxxxxxxxx> wrote: > On Thu, December 13, 2007 11:38 pm, Rashmi Badan wrote: > > I'm using php 5.2.1 with apache 2.2.6 and while running certain tests > > I see > > a segmentation fault - the relevant stack is given below. My php > > configure > > line is as follows > > > > configure '--prefix=/my/php/installdir' *'--with-tsrm-pthreads' > > *'--with-ldap' > > *'--enable-maintainer-zts'* '--enable-sigchild' '--enable-so' > > '--with-apxs2=/my/apache2/bin/apxs' '--without-sqlite' > > '--without-pdo-sqlite' '--with-oci8=/my/oracle/installdir' > > '--enable-mbstring' > > > > I'm running apache with a threaded MPM. Is that a probem as I remember > > reading somewhere that php does not quite work well with threaded > > MPMs. > > Would appreciate any help/pointers on this. > > PHP itself works fine with MPM, as far as anybody knows. > > But one of your --enable-xyz may NOT work fine with MPM! > > PDO is "new" and suspect. > "mbstring" is on the way out in favor of PHP 6 Unicode, and I think > it's also suspect. > OCI8, well, I dunno... You'd think enough folks would be using that > to get rid of all the thread-bugs, but... > > > ----------------------------------- > > #0 0x007937a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 > > #1 0x007d7c96 in kill () from /lib/tls/libc.so.6 > > #2 0x08070da8 in sig_coredump () > > #3 <signal handler called> > > #4 0x00a00d24 in pthread_mutex_lock () from /lib/tls/libpthread.so.0 > > *#5 0xb461d9f5 in tsrm_mutex_lock (mutexp=0x0) > > at /ade/rbadan_gollum/oracle/apache_modules/mod_php/php-5.2.1 > > /TSRM/TSRM.c:660 > > #6 0xb461d071 in ts_resource_ex (id=0, th_id=0x0)* > > at /ade/rbadan_gollum/oracle/apache_modules/mod_php/php- 5.2.1 > > /TSRM/TSRM.c:345 > > #7 0xb472dcb5 in php_handler (r=0x85c65b0) > > at /ade/rbadan_gollum/oracle/apache_modules/mod_php/php-5.2.1 > > /sapi/apache2handler/sapi_apache2.c:500 > > #8 0x080829af in ap_run_handler () > > #9 0x08082807 in ap_invoke_handler () > > #10 0x080976d5 in async_run_handlers () > > #11 0x080975f3 in async_process_connection () > > #12 0x08097346 in process_socket () > > #13 0x08096e97 in worker_thread () > > #14 0xb7f83e33 in dummy_worker (opaque=0x85bf438) at > > threadproc/unix/thread.c:142 > > #15 0x009ff371 in start_thread () from /lib/tls/libpthread.so.0 > > #16 0x008779be in clone () from /lib/tls/libc.so.6 > > You probably should post this into: > http://bugs.php.net > > It is a pretty cogent error report. > > If you can provide source code for the tests that make this segfault, > then odds are extremely good that somebody on the PHP Dev Team can > reproduce it and fix it. > > -- > Some people have a "gift" link here. > Know what I want? > I want you to buy a CD from some indie artist. > http://cdbaby.com/from/lynch > Yeah, I get a buck. So? > >
