php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #13344 sablot bites ext/java (sun jdk 1.3.1 & 1.4)
Submitted: 2001-09-17 06:56 UTC Modified: 2002-09-10 07:03 UTC
From: chregu@php.net Assigned:
Status: Closed Package: Java related
PHP Version: 4.0CVS-2002-09-10 OS: debian unstable
Private report: No CVE-ID: None
 [2001-09-17 06:56 UTC] chregu@php.net
If i compile php wit ext/xslt and ext/java, new java segfaults.

here the system:

jdk 1.3.1 from sun
java -version:
java version "1.3.1"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1-b24)
Java HotSpot(TM) Client VM (build 1.3.1-b24, mixed mode)

php cvs-branch php_4_0_7

configure:
"./configure" \
"--with-config-file-path=/usr/local/apache/conf" \
"--enable-debug=yes" \
"--with-apxs=/usr/local/apache/bin/apxs" \
"--with-java=/usr/lib/java" \
"--enable-xslt" \
"--with-xslt-sablot" \

testscript:

 $system = new Java('java.lang.System');
  print 'Java version='.$system->getProperty('java.version').' <br>';
  print 'Java vendor=' .$system->getProperty('java.vendor').'  <br>';
  print 'OS='.$system->getProperty('os.name').' '.
              $system->getProperty('os.version').' on '.
              $system->getProperty('os.arch').' <br>';


gdb output: 

(no debugging symbols found)...(no debugging symbols found)...[New Thread 1024 (LWP 23557)]
[New Thread 2049 (LWP 23558)]
[New Thread 1026 (LWP 23559)]
[New Thread 2051 (LWP 23560)]
[New Thread 3076 (LWP 23561)]
[New Thread 4101 (LWP 23562)]
[New Thread 5126 (LWP 23563)]
[New Thread 6151 (LWP 23564)]
[New Thread 7176 (LWP 23565)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 7176 (LWP 23565)]
0x400f0860 in free () from /lib/libc.so.6
(gdb) bt
#0  0x400f0860 in free () from /lib/libc.so.6
#1  0x4035116f in Arena::dispose () from /usr/lib/libsablot.so.0
#2  0x403511bc in Arena::~Arena () from /usr/lib/libsablot.so.0
#3  0x40724b77 in ciEnv::~ciEnv ()
   from /usr/lib/java/jre/lib/i386/client/libjvm.so
#4  0x40734663 in CompileBroker::invoke_compiler_on_method ()
   from /usr/lib/java/jre/lib/i386/client/libjvm.so
#5  0x40734118 in CompileBroker::compiler_thread_loop ()
   from /usr/lib/java/jre/lib/i386/client/libjvm.so
#6  0x4071153a in compiler_thread_entry ()
   from /usr/lib/java/jre/lib/i386/client/libjvm.so
#7  0x4070e17f in JavaThread::thread_main_inner ()
   from /usr/lib/java/jre/lib/i386/client/libjvm.so
#8  0x4070e12b in JavaThread::run ()
   from /usr/lib/java/jre/lib/i386/client/libjvm.so
#9  0x406dc023 in _start () from /usr/lib/java/jre/lib/i386/client/libjvm.so
#10 0x4092ce85 in pthread_start_thread () from /lib/libpthread.so.0
#11 0x4092cecd in pthread_start_thread_event () from /lib/libpthread.so.0
(gdb) 


Hope someone still does maintain ext/java (it's quite useful in some situations..)

chregu




Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-02-13 16:55 UTC] phpbugs at wschmidt dot leute dot server dot de
I have the same problem:

PHP 4.1.1

Debian Linux 2.2 with all updates as of 1st Feb. 2002

Apache 1.3.23 (or Apache delivered with debian, doesn't matter)

Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_02-b02)
Java HotSpot(TM) Client VM (build 1.3.1_02-b02, mixed mode)
(or JDK 1.3.1_01, doesnt' matter)

Sablotron 0.71 or 0.82 (doesn't matter)

./configure \
        --with-tsrm-pthreads \
        --prefix=/opt/apache-1.3.23/php-4.1.1 \
        --with-apxs=/opt/apache-1.3.23/bin/apxs \
        --enable-xslt \
        --with-xslt-sablot=/opt/local \
        --enable-sablot-errors-descriptive

Adding 50 other directives doesn't matter. As soon
as I remove --enable-xslt and --with-xslt-sablot
"new Java(...)" works.
 [2002-02-24 06:14 UTC] yohgaki@php.net
Please test with  PHP 4.1.1+JDK 1.2 and report the result back 
Please do not forget  updating PHP version. Thanks.
 [2002-02-24 06:30 UTC] chregu@php.net
It always worked with JDK 1.2... 

And i don't think, there was much of a change in ext/java or ext/xslt from 2001-09-1 till today (in the 4.1 branch, don't know about HEAD)

anyway, i use at the moment JDK 1.2, so this is not that important for me, someone else has to verify it (maybe giving JDK 1.4 a try)
 [2002-04-19 18:01 UTC] asael at brm dot bireme dot br
The system:
PIII 1GHz 512Mb RAM
Red Hat 7.1 (kernel 2.4.2-2)
Sun JDK 1.4.0 RC
Apache 1.3.20 (compiled with LDFLAGS...)
PHP 4.0.6 (--with-apxs...)
Sablotron 0.90
Expat 1.95.2

The problem:
PHP compiles fine with Apache (DSO) and Sablotron/Expat.
When compiling with JDK, pure PHP+XML/XSLT code executes fine either via browser or via command line. Any java code inserted and core dumps and segmentation faults appear.
If compiling Apache, PHP and JDK, simple PHP+Java code resumes fine in both modes (command line/browser).
I noticed that related problems had been already reported with different versions, but they'd never solved.
I also read someone arguing why is that someone would use PHP and Java and I got twisted.
The issue:
There's an application project I'm working with where we use PHP code to execute a database query (via WWWISIS), returning a XML content that is transformed with XSLT. This is already done with PHP/Sablot/Expat. But, with java, we would execute multiple threads, each one collecting a piece of XML data, which bundled together would be then returned to PHP and then transformed.
I appreciate any suggestions.
 [2002-04-25 06:01 UTC] pavel at gingerall dot cz
It's strange from the point of view of Sablotron.

First... Sablotron never performs some thread locking, since the code (if API is used in proper way) is thread safe. It's not absolutely bulletproof, but should work undem most conditions.

What is very suspicious is, that the Arena::~Arena in the backtrace above, is called from some other library, since it should be hidden form other libs and used internally (and called from other Sablotron destructors as a result of this).

Has somebody a clue, what library defines the ciEnv class? It looks like this is a linking problem (and is it even possible?) Could somebody rename Arena to SabArena in the Sablotron source (there are just few occurences) and test it?
 [2002-08-14 12:30 UTC] kalowsky@php.net
can you please try the latest CVS?  I believe I may have fixed this for you... but I could be wrong.  
 [2002-09-10 02:18 UTC] chregu@php.net
Just tested with latest CVS and jdk 1.4 and sablotron 0.96. It still segfaults... with the same bt:

#0  0x40109b00 in free () from /lib/libc.so.6
#1  0x40109aa3 in free () from /lib/libc.so.6
#2  0x403e303f in Arena::dispose () from /usr/lib/libsablot.so.0
#3  0x403e308c in Arena::~Arena () from /usr/lib/libsablot.so.0
#4  0x40c8224c in Compilation::~Compilation () from /usr/lib/java/jre/lib/i386/client/libjvm.so
#5  0x40c48c8d in Compiler::compile_method () from /usr/lib/java/jre/lib/i386/client/libjvm.so
#6  0x40c352d9 in CompileBroker::invoke_compiler_on_method ()
   from /usr/lib/java/jre/lib/i386/client/libjvm.so
#7  0x40c34db9 in CompileBroker::compiler_thread_loop () from /usr/lib/java/jre/lib/i386/client/libjvm.so
#8  0x40c06c36 in compiler_thread_entry () from /usr/lib/java/jre/lib/i386/client/libjvm.so
#9  0x40c0762a in JavaThread::thread_main_inner () from /usr/lib/java/jre/lib/i386/client/libjvm.so
#10 0x40c03b90 in JavaThread::run () from /usr/lib/java/jre/lib/i386/client/libjvm.so
#11 0x40bcd10a in _start () from /usr/lib/java/jre/lib/i386/client/libjvm.so
#12 0x40e530ba in pthread_start_thread () from /lib/libpthread.so.0
#13 0x40e53101 in pthread_start_thread_event () from /lib/libpthread.so.0

 [2002-09-10 03:41 UTC] chregu@php.net
It's maybe clear for everyone, but both (sablotron and libjvm) have obviously a class called Arena in the global namespace... This class is not used in the php-source-code, but libjvm.so calls it on destruction of some compiling stuff. 

I'm by no way the compiling, resp c++ expert to resolve this problem, but maybe someone else has an idea. Would be great :)

chregu
 [2002-09-10 04:28 UTC] chregu@php.net
Hi

I found the solution (as suggested by pavel)

I did a quick search&replace (Arena to SabArena) in Sablot/src/engine and now it doesn't segfault anymore...

I will check with the Sablot guys, what they think of it.

chregu
 [2002-09-10 07:03 UTC] chregu@php.net
Good news from Sablotron.

They will change this in the next release (0.97?) and therefore we can close now this almost one year old bug. 

chregu
 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Tue Nov 30 03:03:16 2021 UTC