[urgent] HPUX + PHP3 + ORACLE -> Stronghold core dumps

[Santiago Romero]

 Hi!

 I'm using IMP 2.2.5 with horde 1.2.4, Apache Stronghold 3 (a
 simple Apache 1.3.9+ modssl), PHP 3.0.18 and Oracle.
 
 I have a big problem... browsing Apache-Stronghold's logfiles
 I've noticed LOTS of messages like:

[Mon Jul  9 15:19:43 2001] [notice]
   child pid 28827 exit signal Segmentation fault (11),
   possible coredump in /opt/apli/dintranet/stronghold3/apache_sh3
[Mon Jul  9 15:29:27 2001] [notice]
   child pid 7555 exit signal Segmentation fault (11),
   possible coredump in /opt/apli/dintranet/stronghold3/apache_sh3
(etc etc etc etc)

 No another warnings nor errors, all works perfectly (IMP is working
 fine) except for the above: sometimes an apache child dies. If all
 the apache child would die, I would think it's an Apache problem,
 but this happens only sometines...

 Efectively, the ServerRoot contains a core file (date = the last
 coredump message of the logfile)...

 I saw the following when compiling php3:

+--------------------------------------------------------------------+
| Notice:                                                            |
| If you encounter <defunc> processes when using a local Oracle-DB   |
| please recompile PHP and specify --enable-sigchild when configuring|
| (This problem has been reported un Linux using Oracle >= 8.1.5)    |
+--------------------------------------------------------------------+

 But the processes are not defunc, they just core and disappear, so
 I'm not sure the problem is the above... In fact, i've tested it
 with --enable-sigchild and I get the same results...

 I've noticed the following:
 
 http://www.php.net/bugs.php?id=900
 
 But it's said to be close :?

 When stronghold says "Segmentation fault" I get a Document No Data
 error on the web client...

 I've done a simple debugging of the core dump and I get:

Core was generated by `httpd'.
Program terminated with signal 11, Segmentation fault.

warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.

(gdb) bt
#0  0xc01f2740 in kill () from /usr/lib/libc.2
#1  0x1a15a0 in sig_coredump ()
#2  <signal handler called>
#3  0xcda50 in read_next_token (tcm=0x40049b20, token=0x77ff1eb8, 
    phplval=0x77ff1d58) at token_cache.c:161
#4  0xb2f68 in phplex (phplval=0x77ff1d58) at main.c:488
#5  0xbb9d8 in phpparse () at /usr/lib/bison.simple:432
#6  0xb5974 in php3_parse (yyin=0x40113c98) at main.c:1564
#7  0xb5ed8 in apache_php3_module_main (r=0x400cd840, fd=26,
    display_source_mode=0, preprocessed=0) at main.c:1929
#8  0xb18a4 in send_php3 ()
#9  0xb1970 in send_parsed_php3 ()
#10 0x197204 in ap_invoke_handler ()
#11 0x1ab36c in process_request_internal ()
#12 0x1ab3ec in ap_process_request ()
#13 0x1a2ff8 in child_main ()
#14 0x1a3254 in make_child ()
#15 0x1a35b8 in perform_idle_server_maintenance ()
#16 0x1a3b78 in standalone_main ()
#17 0x1a45c8 in main ()

 The line 161 of php3/token_cache.c is:

GLOBAL(tc)->tokens[GLOBAL(tc)->count] = next_token;

 I have no idea of what's happening! I firstly thought it was
 an HPUX + oracle related problem, but I also had the same problem
 on a Linux machine with postgresql + oracle...

 It's clear that is a bug cause by PHP3 interpretation of the
 webmail code... Surely is not an IMP bug, but maybe anyone here
 as an idea to solve this... Maybe PHP4 solves this? 

 thanks a lot for any help.

 
-- 
Santiago Romero
Departamento de Sistemas
sromero@servicom2000.com

Av. Primado Reig 189, entlo
46020 Valencia - Spain
Telf. (+34) 96 332 12 00
Fax. (+34) 96 332 12 01
http://www.servicom2000.com