Bug #4873
closed
JETVM crash on some linux servers
100%
Description
Hi,
Following #4864, we began using Saxon-C PE edition to write custom XSLT extensions in PHP.
I first used an evaluation license and used v1.2.1 on my own workstation (Debian 10). I experienced weird crashs but it seemed to me they were due to either or/and (I would say OR: 1) execution of php script in home directory 2) PHP extnesion function name was too long. So a shorter one in /tmp or /opt for example was OK. I still need to take some time to report that to you with more details.
Then, we wanted to deploy on our dev server (Debian 10) with a paid PE license. No luck this time, it fails at all times.
With 1.1.2 (we still use this version due to blocking bug: #4371
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
__lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:63
63 ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory.
(gdb) backtrace
#0 __lll_lock_wait_private () at ../sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:63
#1 0x00007f952f95af1e in __GI___libc_realloc (oldmem=oldmem@entry=0x55d7c8193690, bytes=bytes@entry=64)
at malloc.c:3220
#2 0x00007f952f94e477 in _IO_vasprintf (result_ptr=0x7ffe65206290, format=<optimized out>,
args=args@entry=0x7ffe652061b0) at vasprintf.c:81
#3 0x00007f952f92e834 in ___asprintf (string_ptr=string_ptr@entry=0x7ffe65206290,
format=format@entry=0x7f953009d028 "%s%s%s") at asprintf.c:35
#4 0x00007f953009c8b9 in __dlerror () at dlerror.c:95
#5 0x00007f9528b4705a in ?? () from /usr/lib/libsaxonpec.so
#6 0x0000000000000000 in ?? ()
with 1.2.1
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `php TestSaxon.php'.
Program terminated with signal SIGABRT, Aborted.
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
[Current thread is 1 (Thread 0x7f2d906b9b80 (LWP 27518))]
(gdb) backtrace
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1 0x00007f2d92765535 in __GI_abort () at abort.c:79
#2 0x00007f2d8ba55634 in ?? () from /usr/lib/libsaxonpec.so
#3 0x0000000000000000 in ?? ()
tested on another Debian 10 server with same result :/
Updated by sébastien bocahu almost 4 years ago
1.1.2:
JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR: system exception at 0x00007f952f957710 Please, contact the vendor of the application. Core dump will be written to "/var/www/saxon-df/core"
Signal 11 (SIGSEGV) siginfo: si_signo 11, si_errno 0, si_code 1, si_addr 0x00007f952d694078
Updated by O'Neil Delpratt almost 4 years ago
- Status changed from New to In Progress
Hi,
Is it possible we can organise a screen share to investigate further please? Feel free to reach me by email.
Updated by sébastien bocahu almost 4 years ago
Hi,
Did you receive my email 'Saxon-C PE crashs with PHP user function' sent on 2021/01/11/01 at 2pm ?
Updated by O'Neil Delpratt almost 4 years ago
Hi, which email account did you use?
Updated by O'Neil Delpratt almost 4 years ago
Update on investigation:
I managed to get your PHP script to work by extracting the functions within the class XSLTGenericExtensions to independent functions in the file ‘XSLTExtensions.php’.
I think the problem is we are not accepting class functions as user defined extensions within the Saxon/C XSLT.
Therefore one workaround is to move the top level PHP extension function (i.e. ‘parse_fc’) out of the class. It might be better to move all functions used in the extension function out of the class. This will probably mean that you have to redesign your code, but I hope this workaround will be ok for you?
Updated by O'Neil Delpratt almost 4 years ago
Having addressed comment #6 the code works perfectly fine on my ubuntu machine, but on the user's dev server (Debian 10) we are now getting the following failure:
Thread 1 "php" received signal SIGSEGV, Segmentation fault.
0x00007ffff46adbda in phpNativeCall (env=<optimized out>, object=<optimized out>, funcName=<optimized out>, arguments=0x7ffdbb7e0df1, argTypes=0x7ffdbb7e0e19) at /usr/include/php/20190902/Zend/zend_string.h:158
158 ZSTR_VAL(ret)[len] = '\0';
This error is coming from the function phpNativeCall in the file php7_saxon.cpp:
case enumString:
stri = senv->GetStringUTFChars((jstring)argObj, nullptr);
_ZVAL_STRING(php_argv[i]._val, stri);
break;
In this code we are converting the arguments from the XSLT to something the PHP extension function can accept. This is a strange difference between machines, but the cause is unclear as we are running against the same PHP version and same Saxon/C product.
This may turn out to be a memory corruption issue, which can be difficult to track down. Still investigating.
Updated by O'Neil Delpratt almost 4 years ago
- Category set to PHP API
- Status changed from In Progress to Resolved
- Assignee set to O'Neil Delpratt
- % Done changed from 0 to 100
The segmentation error is caused by the use of the new to create the struct variable php_argv in the phpNativeCall function in the php7_saxon.cpp file.
The php_argv contains an zval attribute. We should probably use malloc, but I have managed to simplify the code to just use the zval without wrapping it in a struct.
Bug fixed and committed to git repository.
Updated by O'Neil Delpratt almost 4 years ago
In comment #6 I mentioned that "we are not accepting class functions as user defined extensions "
This is not true as the user confirmed that "PHP functions using an abstract class and static functions works as well"
Updated by O'Neil Delpratt almost 3 years ago
- Status changed from Resolved to Closed
- Fixed in version set to 11.1
Bug fix patched in SaxonC 11.1 release
Please register to edit this issue
.