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

go to bug id or search bugs for

Bug #8467 Crash in Tomcat with PHP/Servlet feature
Submitted: 2000-12-28 18:18 UTC Modified: 2001-01-23 12:09 UTC
From: akilov at us dot ibm dot com Assigned:
Status: Closed Package: Reproducible Crash
PHP Version: 4.0 Latest CVS (28/12/2000) OS: AIX4.3.2
Private report: No CVE-ID: None
View Developer Edit
 [2000-12-28 18:18 UTC] akilov at us dot ibm dot com 
Trying to get PHP built on AIX with the IBM C compiler.

The setup I used is as follows:

CC=xlc_r
CFLAGS="-ma -g -Dinline= "
CXX=xlC_r
./configure --without-xml --without-mysql --with-servlet --with-java
The JDK level is IBM118.

Had to hack servlet.c and ext/java/config.m4 to make sure the
compile and link work.  The change needed to servlet.c is to
rename the sapi_module structure to sapi_module_servlet since
the IBM compiler doesn't allow duplication of struct names.  The
ext/java/config.m4 fix is to make it look for libjava.a instead of
the hardcoded libjava.so.

The configure/make/install work with the above setup although
there are quite a few warnings about type conversions and invalid
suffix (.lo).

Start Tomcat and attempt to invoke a PHP file and get a core
and a stack dump which points at open_file_for_scanning.
I tracked it down to the first instantiation of the 
istdiostream class.  More specifically, in zend_language_scanner.l >>
open_file_for_scanning() in the ZEND_HANDLE_FP case
(ZTS).  The file_handle and file_handle->handle.fp are not 
null but the file_handle->handle.is assignment never completes.

The native stack contains:

open_file_for_scanning
compile_file
zend_execute_scripts
php_execute_script
Java_net_php_servlet_send

Called from net.php.servlet.service() in Java.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2000-12-28 18:35 UTC] akilov@php.net 
Finally figured out how to get a gdb backtrace (sorry, my first time).
Here's the relevant section:

#5  0xd6ec80a8 in open_file_for_scanning (file_handle=0x209ce358,
    compiler_globals=0x20250a38) at ./zend_language_scanner.l:297
#6  0xd6ec78c8 in compile_file (file_handle=0x209ce358, type=2,
    compiler_globals=0x20250a38) at ./zend_language_scanner.l:345
#7  0xd6eafe20 in zend_execute_scripts (type=8, compiler_globals=0x20250a38,
    executor_globals=0x202548a8, file_count=3) at zend.c:738
#8  0xd6f1ab0c in php_execute_script (primary_file=0x209ce358,
    compiler_globals=0x20250a38, executor_globals=0x202548a8,
    core_globals=0x202581d8) at main.c:1209
#9  0xd6f950b8 in Java_net_php_servlet_send (jenv=0x209cef04, self=0x4,
    requestMethod=0x3, queryString=0x0, requestURI=0x2, pathTranslated=0x1,
    contentType=0x0, contentLength=-1, authUser=0x0,
    display_source_mode=0 '\000') at servlet.c:409
 [2001-01-12 15:57 UTC] akilov at us dot ibm dot com 
Tried again today with the latest CVS but still getting the
problem.  Here's the complete gdb backtrace (sorry for
chopping it in half before):

#0  0xd1830484 in abort ()
#1  0xd0bdfe64 in pthread_rwlock_destroy ()
#2  0xd0bf0c48 in pthread_rwlock_destroy ()
#3  <signal handler called>
#4  0xd2e951d0 in operator new ()
#5  0xd2e81094 in open_file_for_scanning
(file_handle=0x209ce358,
    compiler_globals=0x20295328) at
./zend_language_scanner.l:296
#6  0xd2e808c8 in compile_file (file_handle=0x209ce358, type=2,
    compiler_globals=0x20295328) at
./zend_language_scanner.l:343
#7  0xd2e68e28 in zend_execute_scripts (type=8,
compiler_globals=0x20295328,
    executor_globals=0x202a92c8, file_count=3) at zend.c:740
#8  0xd2eb1a88 in php_execute_script (primary_file=0x209ce358,
    compiler_globals=0x20295328, executor_globals=0x202a92c8,
    core_globals=0x202b1ae8) at main.c:1198
#9  0xd2eaed68 in Java_net_php_servlet_send
(jenv=0x209cef04, self=0x4,
    requestMethod=0x3, queryString=0x0, requestURI=0x2,
pathTranslated=0x1,
    contentType=0x0, contentLength=-1, authUser=0x0,
    display_source_mode=0 '\000') at servlet.c:407
#10 0x204a57ac in ?? () from (unknown load module)

Again, to be able to build this correctly, I had to hack the
ext/java/config.m4 to look for libjava.a (instead of
libjava.so).  Will have to fix this in CVS at some point.
 [2001-01-15 16:12 UTC] akilov at us dot ibm dot com 
We found a solution to this problem.  The trick is to use
the following compiler flags:

CC=xlC_r (xlC_r is the IBM C++ compiler)
CXX=xlC_r
CFLAGS="-g -ma -Dinline= "

Previously we had:

CC=xlc_r (xlc_r is the IBM C compiler)
CXX=xlC_r
CFLAGS="-g -ma -Dinline= "

There appears to be another problem here, however.  If you
don't --enable-debug on the configure statement, the third
php page requested crashes Tomcat.  It appears to be dying
in the memory manager but the place where it dies is
different everytime (although in the end it's usually in
_efree).  I'm, therefore, not going to bother with appending
the gdb backtrace but will look at the php/servlet code to
see if I can spot any obvious reentrancy problems.
 [2001-01-23 12:09 UTC] akilov at us dot ibm dot com 
Closing since the original problem on AIX is solved.  I will open a different bug for the Zend_hash memory problem.
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved. 		Last updated: Sun Jun 28 21:00:01 2026 UTC