Bug #3977
closedXdmAtomicValue problems when deleting object - JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR
100%
Description
Reported by user:
It appears that under certain conditions that the creation of XdmAtomicValue
i.e. via makeStringValue()
function on the SaxonProcessor once this function is called, a subsequent call to SaxonProcessor's release() will reliably cause the crash, if the XdmAtomicValue instance is not destroyed first.
#include "../saxonpy/include/saxon/SaxonProcessor.h"
#include "../saxonpy/include/saxon/XdmAtomicValue.h"
#include <iostream>
#include <memory>
using namespace std;
void saxon_cpp()
{
cout << "CPP Creating Saxon Processor\n";
shared_ptr<SaxonProcessor> sp( new SaxonProcessor(true) );
cout << "CPP Making String Value\n";
// **** REMOVE BRACES FOR ERROR ****
{
shared_ptr<XdmAtomicValue> msv( sp->makeStringValue("Some String") );
}
cout << "CPP Releasing Saxon Processor\n";
SaxonProcessor::release();
return;
}
int main()
{
saxon_cpp();
return 0;
}
Output:
CPP Creating Saxon Processor
Library length: 15
Env length: 8
dllname length alloc: 24
resources length alloc: 20
size of dllname 23
dllName: /usr/lib/libsaxoneec.so
resources_dir: /usr/lib/saxon-data
size of resources dir 19
/usr/lib/libsaxoneec.so loaded
initJavaRT - load Saxon/C library
: Success
Class net/sf/saxon/Version found
Class net/sf/saxon/s9api/Processor found
Class net/sf/saxon/option/cpp/SaxonCAPI found
Class net/sf/saxon/s9api/XdmAtomicValue found
CPP Making String Value
CPP Releasing Saxon Processor
JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR: system exception at 0x0000000000000000
Please, contact the vendor of the application.
Core dump will be piped to "/usr/share/apport/apport %p %s %c %d %P"
Extra information about error is saved in the "jet_err_25486.txt" file.
Fatal Error: Crash during termination.
Aborted (core dumped)
If I run the program using gdb and handle the SIG35 error with the following command:
gdb ./testValidator
(gdb) handle SIG35 noprint nostop
(gdb) run
(gdb) bt
Output:
#0 0x0000000000000000 in ?? ()
#1 0x00000000004073da in JNIEnv_::DeleteLocalRef (this=0x882d90, obj=0x7ffaf54b16f9)
at ../../Saxon.C.API/jni.h:851
#2 0x00000000004152c4 in XdmItem::~XdmItem (this=0xb97e70, __in_chrg=<optimised out>)
at ../../Saxon.C.API/XdmItem.h:30
#3 0x0000000000416a93 in XdmAtomicValue::~XdmAtomicValue (this=0xb97e70,
__in_chrg=<optimised out>) at ../../Saxon.C.API/XdmAtomicValue.h:30
#4 0x0000000000416ac8 in XdmAtomicValue::~XdmAtomicValue (this=0xb97e70,
__in_chrg=<optimised out>) at ../../Saxon.C.API/XdmAtomicValue.h:34
#5 0x0000000000419fc8 in std::_Sp_counted_ptr<XdmAtomicValue*, (__gnu_cxx::_Lock_policy)2>::_M_dispose (this=0xb97ef0) at /usr/include/c++/5/bits/shared_ptr_base.h:374
#6 0x0000000000419b7a in std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release
(this=0xb97ef0) at /usr/include/c++/5/bits/shared_ptr_base.h:150
#7 0x0000000000419aa7 in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count (this=0x7fffffffdd78, __in_chrg=<optimised out>)
at /usr/include/c++/5/bits/shared_ptr_base.h:659
#8 0x0000000000419a3a in std::__shared_ptr<XdmAtomicValue, (__gnu_cxx::_Lock_policy)2>::~__shared_ptr (this=0x7fffffffdd70, __in_chrg=<optimised out>)
at /usr/include/c++/5/bits/shared_ptr_base.h:925
#9 0x0000000000419a56 in std::shared_ptr<XdmAtomicValue>::~shared_ptr (
this=0x7fffffffdd70, __in_chrg=<optimised out>)
at /usr/include/c++/5/bits/shared_ptr.h:93
#10 0x0000000000419922 in saxon_cpp () at testValidator.cpp:203
#11 0x0000000000419988 in main () at testValidator.cpp:213
Updated by O'Neil Delpratt about 6 years ago
- Category set to C++ API
To reproduce this bug issue I upgraded to g++ version 5.5..0. Running with option -g std=c++14
.
What is happening is the release() function is called before the XdmAtomicValue is destroyed.
In the XdmAtomicValue destructor there is a JNI call to the JVM to delete the local reference to the Java object of the Xdm Value. If the release method has been called then we cannot ask the Jet JVM to perform this delete, which is why the program crashes. Therefore I am not sure that this is actually a bug or maybe we need to look into more how shared_prt works.
I suggested to the user a possible workaround is to stop that bit of code from executing. This can easily be done in their code by setting the Processor to null on the XdmAtomicValue. For example:
msv->setProcessor(NULL);
Updated by O'Neil Delpratt almost 6 years ago
- Status changed from New to Resolved
Bug fixed. In the destructor method of XdmItem I have added a special check using the 'SaxonProcessor::jvmCreatedCPP>0
. This should prevent the crash.
Updated by O'Neil Delpratt almost 6 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in version set to 1.1.2
Bug fix applied in the Saxon/C 1.1.2 maintenance release.
Please register to edit this issue