ID: 27231
Comment by: jason at accordit dot co dot uk
Reported By: herman at frontier dot nl
Status: Verified
Bug Type: iPlanet related
Operating System: SunOS 5.8+
PHP Version: 4CVS-2004-02-13
New Comment:
Experiencing this also on Solaris 9, SunONE Webserver 6.1SP1, using php
4.3.4. Have tried with and without the zend optimzer (v2.1.0), and the
problem still occurs when using large php scripts > 128kb.
The following stack traces produced:
Without Zend Optimizer:-
The stacktrace from adb is -
bash-2.05# adb /iws61/https-elrond.uk.sun.com/config/core
core file = /iws61/https-elrond.uk.sun.com/config/core -- program
``/iws61/bin/https/bin/webservd'' on platform i86pc
SIGSEGV: Segmentation Fault
$C
c26af648 libphp4.so`execute+0x117f()
c26af688 libphp4.so`zend_execute_scripts+0xd4(8, 8732840, 0, 3, 0,
c26afc40)
c26afb58 libphp4.so`php_execute_script+0x1b6()
c26afc78 libphp4.so`php4_execute+0x54e(807a348, 88698dc, 8869950)
c26afcdc
libns-httpd40.so`__1cNfunc_exec_str6FpnKFuncStruct_pnGpblock_pnHSession_pnHRequest__i_+0x21c(8079038,
807a348,
88698dc, 8869950)
c26afd14 libns-httpd40.so`INTobject_execute+0x262(828ba38, 88698dc,
8869950)
c26afd94 libns-httpd40.so`INTservact_service+0x37a(88698dc, 8869950)
c26afdc4 libns-httpd40.so`INTservact_handle_processed+0x11d(88698dc,
8869950)
c26afdfc
libns-httpd40.so`__1cLHttpRequestUUnacceleratedRespond6Mpc_v_+0x631(8869840,
8bc0b68)
c26aff70
libns-httpd40.so`__1cLHttpRequestNHandleRequest6MpnGnetbuf__i_+0x644(8869840,
8bbeae0)
c26affac libns-httpd40.so`__1cNDaemonSessionDrun6M_v_+0x217(8869438)
c26affc0 libnsprwrap.so`ThreadMain+0x25(8869438)
dd58a4c4 libnspr4.so`_pt_root+0xc4()
080982a8 0x80743a8()
00000004 0x4d580000()
8732840::dump
/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
8732840: 006a6b08 17000000 47000000 00000000 .jk.....G.......
c26afc40::dump
/ 1 2 3 4 5 6 7 8 9 a b c d e f v123456789abcdef
c26afc40: 01000000 d017bc08 00e1f508 1f000000 ................
With zend optimizer:-
/opt/iws61/https-cherokee.accordit.co.uk/config
bash-2.05# adb /opt/iws61/https-cherokee.accordit.co.uk/config/core
core file = /opt/iws61/https-cherokee.accordit.co.uk/config/core --
program ``
/opt/iws61/bin/https/bin/webservd'' on platform SUNW,UltraAX-i2
SIGSEGV: Segmentation Fault
$C
e372f840 0xe3c18c34(400, 0, 696248, fd366f2c, 11c45c8, 28)
e374f3e8 ZendOptimizer.so`zend_oe+0xc(11ba1e8, 696248, e374f4bc,
6833b0, c48080
, fd3e2590)
e374f458 libphp4.so`zend_execute_scripts+0xec(8, 696248, 0, 3,
fd3e2564,
e374fab8)
e374f4d0 libphp4.so`php_execute_script+0x244(0, 0, 2ef8, 9dd528, 8000,
f000)
e374f9c0 libphp4.so`php4_execute+0x578(3a618, c46cf8, c46d70, 0, 0,
2c00)
e374fae0
libns-httpd40.so`__1cNfunc_exec_str6FpnKFuncStruct_pnGpblock_pnHSession_pnHReque
st__i_+0x248(664, 3a618, c46cf8, c46d70, 0, 0)
e374fb60 libns-httpd40.so`INTobject_execute+0x5e8(24c130, c46cf8,
c46d70, 0,
391c8, 24bff0)
e374fbc0 libns-httpd40.so`INTservact_service+0x4d8(c46cf8, c46d70,
ff2e42dc, 3,
30, ff2e42b4)
e374fc20 libns-httpd40.so`INTservact_handle_processed+0x158(c46cf8,
c46d70, 20,
2, 9dd2e8, 6fb38)
e374fc80
libns-httpd40.so`__1cLHttpRequestUUnacceleratedRespond6Mpc_v_+0x3c8(
c46c58, ff2e42fc, 30f4, 50, c46d70, c46cf8)
e374fce0
libns-httpd40.so`__1cLHttpRequestNHandleRequest6MpnGnetbuf__i_+0x634(
c46c58, 9daae0, 9dcb68, 9dcb58, 2000, 9dab40)
e374fe70 libns-httpd40.so`__1cNDaemonSessionDrun6M_v_+0x430(c46850,
16e,
ff2dcf2c, ff2e9a60, 0, ff2e9a28)
e374fed8 libnsprwrap.so`ThreadMain+0x24(c46850, 682ee8, 3, 0, 400,
4d4)
e374ff38 libnspr4.so`_pt_root+0xd0(682ee8, 0, 0, 0, 20000, fedf8c28)
e374ffa0 libthread.so.1`_lwp_start(0, 0, 0, 0, 0, 0)
696248::dump
0 1 2 3 4 5 6 7 \/ 9 a b c d e f 01234567v9abcdef
696240: 0068ca88 00000000 006833b0 00000018 .h.......h3.....
fd3e2564::dump
0 1 2 3 \/ 5 6 7 8 9 a b c d e f 0123v56789abcdef
fd3e2560: 01000000 00000006 00000000 005b4cf8 .............[L.
Any help, or work around appreciated,
Cheers
Previous Comments:
------------------------------------------------------------------------
[2004-03-15 05:02:25] yshimo at ctc-g dot co dot jp
I have same problem with XOOPS.
Does anybody know any workaround or how to fix this problem?
I think that this is one of important problem for CMS like a XOOPS or
Mambo with iPlanet.
------------------------------------------------------------------------
[2004-02-25 07:22:18] herman at frontier dot nl
As this bug prevent me from rolling-out an application to a client, I
was wondering if any of the PHP developers could elaborate on possible
causes and if there might be a work-around I can try until a solution
has been found. I'm not proficient enough with coding to be of any
assistance with fixing the bug, I'm afraid...
------------------------------------------------------------------------
[2004-02-14 11:40:49] [EMAIL PROTECTED]
Can not reproduce with apache2-worker.
------------------------------------------------------------------------
[2004-02-13 18:32:00] [EMAIL PROTECTED]
You do not need to test ist on your system. I can reproduce the crashs
here, even with the latest stable snapshot.
I think we should try to reproduce this with other multithreaded
servers to check if it is a ZTS bug (I think it is one).
------------------------------------------------------------------------
[2004-02-13 09:00:58] [EMAIL PROTECTED]
Same on PHP 4.3.5 RC2 of SunOS 5.9. Tried to debug it but the crashing
process did not create a core dump.
If somebody of the others helps this:
# /opt/forte7/SUNWspro/bin/dbx
For information about new features see `help changes'
To remove this message, put `dbxenv suppress_startup_message 7.0' in
your .dbxrc
(dbx) attach 9702
...
...
detected a multithreaded program
Attached to process 9702 with 90 LWPs
[EMAIL PROTECTED] ([EMAIL PROTECTED]) stopped in __lwp_park at 0xfe3e5f88
0xfe3e5f88: __lwp_park+0x0010: ta %icc,%g0 + 8
(dbx) cont
-> here starting of crashing test2.php
[EMAIL PROTECTED] ([EMAIL PROTECTED]) signal SEGV (no mapping at the fault address) in
zend_clean_garbage at line 25 in file "zend_execute_locks.h"
25 while (EG(garbage_ptr)) {
dbx: read of 4 bytes at address ee2cf748 failed -- Error 0
(dbx) where
current thread: [EMAIL PROTECTED]
=>[1] zend_clean_garbage(tsrm_ls = <bad address 0xee2cf7dc>), line 25
in "zend_execute_locks.h"
dbx: read of 4 bytes at address ee2cf7b8 failed -- Error 0
dbx: attempt to read frame failed -- cannot derive frame pointer
(dbx)
seems to be a TSRM problem because in CLI it does not appear. And crash
is not in NSAPI code.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/27231
--
Edit this bug report at http://bugs.php.net/?id=27231&edit=1
