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 Add Comment Developer Edit
 [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

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved. 		Last updated: Sun May 05 10:01:31 2024 UTC