|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #27231 Large-size PHP script crashes SunONE webserver
Submitted: 2004-02-12 14:59 UTC Modified: 2004-03-18 08:42 UTC
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.
Block user comment
Status: Assign to:
Bug Type:
From: herman at frontier dot nl
New email:
PHP Version: OS:


 [2004-02-12 14:59 UTC] herman at frontier dot nl
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:

echo "hello";

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

The scripts can be found at: => WORKS => CRASH

Include examples: => WORKS => CRASH

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


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-02-12 20:52 UTC]
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]
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

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]
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]
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/
core file = /iws61/ -- program ``/iws61/bin/https/bin/webservd'' on platform i86pc
SIGSEGV: Segmentation Fault
c26af688`zend_execute_scripts+0xd4(8, 8732840, 0, 3, 0, c26afc40)
c26afc78`php4_execute+0x54e(807a348, 88698dc, 8869950)
c26afcdc`__1cNfunc_exec_str6FpnKFuncStruct_pnGpblock_pnHSession_pnHRequest__i_+0x21c(8079038, 807a348,
88698dc, 8869950)
c26afd14`INTobject_execute+0x262(828ba38, 88698dc, 8869950)
c26afd94`INTservact_service+0x37a(88698dc, 8869950)
c26afdc4`INTservact_handle_processed+0x11d(88698dc, 8869950)
c26afdfc`__1cLHttpRequestUUnacceleratedRespond6Mpc_v_+0x631(8869840, 8bc0b68)
c26aff70`__1cLHttpRequestNHandleRequest6MpnGnetbuf__i_+0x644(8869840, 8bbeae0)
080982a8 0x80743a8()
00000004 0x4d580000()
          / 1 2 3  4 5 6 7  8 9 a b  c d e f  v123456789abcdef
8732840:  006a6b08 17000000 47000000 00000000  .jk.....G.......
           / 1 2 3  4 5 6 7  8 9 a b  c d e f  v123456789abcdef
c26afc40:  01000000 d017bc08 00e1f508 1f000000  ................ 

With zend optimizer:-

bash-2.05# adb /opt/iws61/
core file = /opt/iws61/ -- program ``
/opt/iws61/bin/https/bin/webservd'' on platform SUNW,UltraAX-i2
SIGSEGV: Segmentation Fault
e372f840 0xe3c18c34(400, 0, 696248, fd366f2c, 11c45c8, 28)
e374f3e8`zend_oe+0xc(11ba1e8, 696248, e374f4bc, 6833b0, c48080
, fd3e2590)
e374f458`zend_execute_scripts+0xec(8, 696248, 0, 3, fd3e2564,
e374f4d0`php_execute_script+0x244(0, 0, 2ef8, 9dd528, 8000, f000)
e374f9c0`php4_execute+0x578(3a618, c46cf8, c46d70, 0, 0, 2c00)
st__i_+0x248(664, 3a618, c46cf8, c46d70, 0, 0)
e374fb60`INTobject_execute+0x5e8(24c130, c46cf8, c46d70, 0,
391c8, 24bff0)
e374fbc0`INTservact_service+0x4d8(c46cf8, c46d70, ff2e42dc, 3,
30, ff2e42b4)
e374fc20`INTservact_handle_processed+0x158(c46cf8, c46d70, 20,
2, 9dd2e8, 6fb38)
c46c58, ff2e42fc, 30f4, 50, c46d70, c46cf8)
c46c58, 9daae0, 9dcb68, 9dcb58, 2000, 9dab40)
e374fe70`__1cNDaemonSessionDrun6M_v_+0x430(c46850, 16e,
ff2dcf2c, ff2e9a60, 0, ff2e9a28)
e374fed8`ThreadMain+0x24(c46850, 682ee8, 3, 0, 400, 4d4)
e374ff38`_pt_root+0xd0(682ee8, 0, 0, 0, 20000, fedf8c28)
e374ffa0`_lwp_start(0, 0, 0, 0, 0, 0)
          0 1 2 3  4 5 6 7 \/ 9 a b  c d e f  01234567v9abcdef
696240:  0068ca88 00000000 006833b0 00000018  .h.......h3.....
            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,

 [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]
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]
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 Jun 18 03:01:31 2024 UTC