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

go to bug id or search bugs for

Bug #21804 php crashes iPlanet - php4_execute
Submitted: 2003-01-21 13:25 UTC Modified: 2003-01-31 22:31 UTC
From: dwells at amgen dot com Assigned:
Status: Not a bug Package: Reproducible crash
PHP Version: 4.3.1-dev OS: Solaris 8
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: dwells at amgen dot com
New email:
PHP Version: OS:

 

 [2003-01-21 13:25 UTC] dwells at amgen dot com 
I can reliably crash iPlanet by running "http_load 
-parallel 5" by concurrently using both of the two scripts below. This is like 20613, but that was fixed in Nov and I have this problem now with a current version of php. I have found no resolution except to run php single-threaded - stable, but hardly an option for a 100-user app that makes Oracle queries... 

I have reproduced this with iPlanet 6.0sp2 and 6.0sp5, php4.2.3, php 4.3.0, and php4-STABLE-200301140030, running on a 280R and an Ultra 2. I built php using gcc 2.95.3 with these options:
  --prefix=/shared/gnu \
  --with-config-file-path=$prefix/../lib \
  --enable-discard-path --enable-tracking  \
  --enable-libgcc --with-ndbm \
  --with-ldap=<openldap 2.0.27 path> \
  --with-oracle=<oracle 8.1.7.2 path> \
  --without-mysql --with-nsapi=<iplanet path>
The error I see is:
 catastrophe (1625): Server crash detected (signal SIGSEGV)
 info (1625): Crash occurred in NSAPI SAF php4_execute
 info (1625): Crash occurred in function strlen from  module /usr/lib/libc.so.1

Here is the back trace:
(gdb) bt
#0  0xfea33344 in strlen () from /usr/lib/libc.so.1
#1  0xfd6b3e90 in _estrdup (s=0xb8 <Address 0xb8 out of bounds>)
    at /shared/gnu/src/php-4.2.3/Zend/zend_alloc.c:322
#2  0xfd738948 in php_print_info (flag=32, tsrm_ls=0x8600e8)
    at /shared/gnu/src/php-4.2.3/ext/standard/info.c:273
#3  0xfd73935c in zif_phpinfo (ht=0, return_value=0x8d6c18, this_ptr=0x0, 
    return_value_used=0, tsrm_ls=0x8600e8)
    at /shared/gnu/src/php-4.2.3/ext/standard/info.c:471
#4  0xfd6c2740 in execute () from /opt/local/php/lib/nsapi/libphp4.so
#5  0xfd6d50d0 in zend_execute_scripts (type=8, tsrm_ls=0x8600e8, retval=0x0, 
    file_count=3) at /shared/gnu/src/php-4.2.3/Zend/zend.c:812
#6  0xfd6e4368 in php_execute_script (primary_file=0xfaef1b48, 
    tsrm_ls=0x8600e8) at /shared/gnu/src/php-4.2.3/main/main.c:1383
#7  0xfd6e0b90 in nsapi_module_main (request_context=0x0, tsrm_ls=0x8600e8)
    at /shared/gnu/src/php-4.2.3/sapi/nsapi/nsapi.c:462
#8  0xfd6e0d1c in php4_execute (pb=0x3d47f8, sn=0x6e3a90, rq=0x6e3ad8)
    at /shared/gnu/src/php-4.2.3/sapi/nsapi/nsapi.c:513
#9  0xff239b14 in __0Fcfunc_native_pool_thread_mainP6NNSTPWorkArg_s ()
   from /opt/local/netscape/dev/iws60sp5/bin/https/lib/libns-httpd40.so
#10 0xfe8e16cc in NSTP_ThreadMain ()
   from /opt/local/netscape/dev/iws60sp5/bin/https/lib/libnstp.so
#11 0xfed676a0 in _pt_root ()
   from /opt/local/netscape/dev/iws60sp5/bin/https/lib/libnspr4.so
(gdb) 

Finally, here are the two scripts:
-----------------------
<html>
<body>
<h2>PHP Operational Qualification Test</h2>
<p>
This test displays a "Hello, world." announcment, then a series
of tables describing the PHP environment.
</p>
<p>
The classic announcement: <?php echo("Hello, world."); ?>
</p>
<p>
PHP Info for this installation:
</p>
<?php phpinfo(); ?>
</body>
</html>
----------------------------
<html>
<body>
<h2>PHP Operational Qualification Test: Oracle Connectivity</h2>
<p>
This test connects to an Oracle database and displays some stuff.
</p>
<p>
<?php
  $userid = "dwells";
  putenv("ORACLE_SID=clindev");
  putenv("ORACLE_HOME=/opt/local/newshare/oracle/product/7.3.3.6");
  putenv("TNS_ADMIN=/opt/local/newshare/oracle/product/7.3.3.6/network/admin");
  $query = sprintf("select * from Employee");
  $ncols = $nrows = 7;
  printf("<p>Result size is ".$ncols." cols by ".$nrows." rows.</p>\n");
  print "<table border=1>\n<tr valign=top align=center>\n";
  for ($i=0; $i<$ncols; $i++) {
    printf("<th>col[%s] = %s<br>type[%d] = %s</th>\n",
        $i, "cursor", $i, "hisur");
  }
  print "</tr><tr valign=top align=left>\n";
  for ($j=0; $j<$nrows; $j++) {
    for ($i=0; $i<$ncols; $i++) {
      printf("<td>val[%d, %d] =<br>'%s'</td>", $j, $i, 'howdy');
    }
    printf("\n");
  }
  print "</tr></table>\n";
 ?>
<p>&nbsp;</p>
</body>
</html>
----------------------------

Thanks,
David

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-21 13:29 UTC] dwells at amgen dot com 
Had the wrong email addr...
 [2003-01-22 21:58 UTC] sniper@php.net 
Does the crash happen only with the provided script?
And btw. you should set those envinronment variables
in the system, NOT in the script..
 [2003-01-23 13:08 UTC] dwells at amgen dot com 
It crashes with other scripts as well. Our developers experienced this problem, and I found that these two 
scripts reliably reproduce it.

We set the Oracle variables in the script because multiple applications run in one web server instance - they may not use the same version of Oracle, and they certainly use different sids. 

However, when I commented out the putenv/getenv statements, the test ran cleanly. The "byte count wrong" messages went away too. So we do have a kludge of a work-around. It would be nice to have this fixed.

I'm not clear why setting environment variables in the php script is a bad idea. I would expect each thread to have it's own environment...

Thanks,
David
 [2003-01-29 15:10 UTC] jmt at purplehat dot net 
Bug #21948 may be a related issue.
 [2003-01-29 16:17 UTC] dwells at amgen dot com 
Bug #21948 is a bit different. The crash we get is always in strlen, and only occurs under load when we set environment variables in the script. It sounds like #21948 happens every time, not just under load.

My naive WAG is that the load causes a resource starvation that php does not catch. Thus a segv. But somehow this is related to environment variables. Hmm... Perhaps a bug in the section that allocates memory for env vars?

Thanks
 [2003-01-31 01:10 UTC] dwells at amgen dot com 
I've had more time to look into this, and found that the script below will recreate the crash. Still using http_load -parallel 5, of course. Oh, and I noticed that I accidentally posted the 4.2.3 bt here. I'll post the 4.3.1-dev bt tomorrow.

Thanks

<?php
putenv("SOME_VAR=/this/is/some/value/here/dont/you/think");
?>
 [2003-01-31 22:31 UTC] dwells at amgen dot com 
I finally had time to rectify my ignorance of threads and ran a test. Threads do share environment variables, so putenv is inherently not thread-safe.  Nevermind.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Nov 15 09:00:01 2025 UTC