php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #27231 Large-size PHP script crashes SunONE webserver
Submitted: 2004-02-12 14:59 UTC Modified: 2004-03-18 08:42 UTC
Votes:4
Avg. Score:4.5 ± 0.5
Reproduced:4 of 4 (100.0%)
Same Version:3 (75.0%)
Same OS:3 (75.0%)
From: herman at frontier dot nl Assigned: thetaphi (profile)
Status: Closed Package: iPlanet related
PHP Version: 4CVS-2004-02-13 OS: SunOS 5.8+
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: herman at frontier dot nl
New email:
PHP Version: OS:

 

 [2004-02-12 14:59 UTC] herman at frontier dot nl 
Description:
------------
When trying an PHP application (which uses generated code, some rather quite large files) on Sun server running Solaris 8, the SunONE webserver 6.1 and PHP 4.3.4 using nsapi, one of the scripts crashed the server.

After some experimenting, it seems the size of the script file triggered the crash: a PHP script > 128KB will bring down the server, a script < 128KB will not.

To complicate matters a bit, if a small script includes a large script, the server will also crash, but if a small script will include two "half size" scripts, it will not.

The server seems to run other PHP scripts well, and is also used to run applets through its nsapi interface without problems.

PHP has been compiled as per instructions on the PHP website, with mysql disabled, and ldap and oci8 enabled.



Reproduce code:
---------------
The test scripts consist of:

<?php
echo "hello";
exit;

$a = "123456789012345678901234567890123456789012345678901234567890";
// previous line copied till the script is large enough
?>

The scripts can be found at:

http://www.ozuzo.net/phpbug/test1.php.txt => WORKS
http://www.ozuzo.net/phpbug/test2.php.txt => CRASH

Include examples:

http://www.ozuzo.net/phpbug/test3.php.txt => WORKS
http://www.ozuzo.net/phpbug/test3a.php.txt
http://www.ozuzo.net/phpbug/test3b.php.txt

http://www.ozuzo.net/phpbug/test4.php.txt => CRASH
http://www.ozuzo.net/phpbug/test4a.php.txt

Expected result:
----------------
The word "hello".

Actual result:
--------------
The server crashes with the following message (no entry in the PHP log):

failure (25268): CORE3107: Child process closed admin channel
fine (25268): CORE3061: signal_handler_thread: received signal 18
fine (25268): CORE3049: Primordial process detected child 25296 died: status 11
fine (25268): CORE3050: Is our child, will spawn replacement
fine (25268): CORE3062: Unlinking of /tmp/<servername>/.cgistub_25296 returned -1
fine (25268): CORE3047: Server spawned worker process 25305

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2004-02-12 20:52 UTC] iliaa@php.net 
Does it crash with PHP-CLI?
 [2004-02-13 03:42 UTC] herman at frontier dot nl 
Sorry, forgot to mention: no, using the CLI (at least scripts #1 and #2) they run OK.
 [2004-02-13 09:00 UTC] thetaphi@php.net 
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
t@1 (l@1) stopped in __lwp_park at 0xfe3e5f88
0xfe3e5f88: __lwp_park+0x0010:  ta      %icc,%g0 + 8
(dbx) cont

-> here starting of crashing test2.php

t@85 (l@85) 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: t@85
=>[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.
 [2004-02-13 18:32 UTC] thetaphi@php.net 
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-14 11:40 UTC] sniper@php.net 
Can not reproduce with apache2-worker.
 [2004-02-25 07:22 UTC] 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-03-15 05:02 UTC] 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-03-15 11:00 UTC] jason at accordit dot co dot uk 
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
 [2004-03-18 05:43 UTC] juergen at henge-ernst dot de 
We had the same Problem, how big is your stack-size defined in the magnus.conf - file?
Try using a bigger value than the default of 128KB. We use 
StackSize 524288
and the crashes have vanished. Maybe this should also be documentetd /mention in the installation for iPlanet to chekc the StackSize if SIgSeg-Fault occur
 [2004-03-18 07:55 UTC] thetaphi@php.net 
This could be the reason. I will test this on our webserver with the test scripts and include this in the docs for SunONE.
Because the NSAPI module runs in the process space of the webserver the tread stack size is a limitation for PHP - this is correct.

Thank you! After verifying this and changing the docs i will close this thread.
 [2004-03-18 08:42 UTC] thetaphi@php.net 
Raising the stacksize in the Admin Server fixes this (tested with Windows and Solaris). Documentation is updated (in phpdoc and in the source tarball in file nsapi-readme.txt).
If there are more problems with that reopen the bug.
 [2004-04-01 11:06 UTC] lee at webaroonie dot net 
Verified this fix to work with Sparc/Solaris 9/PHP4.3.5/SunOne WebServer 6.1.
 [2004-06-15 19:10 UTC] tommy dot mcneely at sun dot com 
Verified fix works in Solaris 9 / PHP 4.3.7 / Java Enterprise System R1 (Sun ONE Web Server 6.1 B09/11/2003 19:00)
# grep -i stack config/*
config/magnus.conf:StackSize 524288
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved. 		Last updated: Tue Apr 16 06:01:30 2024 UTC