ID: 13344
Updated by: chregu@php.net
Reported By: chregu@php.net
-Status: Analyzed
+Status: Closed
Bug Type: Java related
Operating System: debian unstable
PHP Version: 4.0CVS-2002-09-10
New Comment:
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
Previous Comments:
------------------------------------------------------------------------
[2002-09-10 04:28:52] 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 03:41:51] 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 02:18:46] 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-08-14 12:30:59] 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-04-25 06:01:01] pavel@gingerall.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?
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/13344--
Edit this bug report at http://bugs.php.net/?id=13344&edit=1