Saxon » SaxonC

Hello!

A Python test resembling the @testXPathSingle@ in the @testXPath.cpp@ file causes a segmentation fault. A @jet_err@ file is generated with "@JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR: system exception at 0x...@" message. The information in the @jet_err@ file points to the @SaxonProcessor::getStringValue()@ method as the cause of the crash. This is the very first real Python test so don't know if others would have similar problems.

Since the Python interface is basically just wrapping the various C++ pointers returned by the Saxon/C library I thought that printing those pointer addresses would be a good way of tracking down what is happing in both the Python and C++ code. Here's the information I gathered:

The @testXPathSingle@ works when I compile the @testXPath.cpp@ file so the SIGSEGV occurs only in the Python test. The difference is that the @environ@ variable in the @SaxonProcessor::getStringValue()@ method is zero for the Python test and not zero for the @testXPath@ executable. This variable is not exposed to Python as I consider it holding internal state so don't know why it appears zero for one SaxonProcessor method.

Below is the debug information, first for the @testXPath@ executable:

C++: In SaxonProcessor::SaxonProcessor(bool l)
C++: l = 0
C++: refCount = 1
C++: before environ = 0
C++: after environ = 0xf1f7d0
C++: environ->myDllHandle = 0x7fbc2c206b40
C++: SaxonProcessor* = 0xf20b90
C++: In SaxonProcessor::newXPathProcessor()
C++: SaxonProcessor* = 0xf20b90
C++: environ = 0xf1f7d0

Test: XPathProcessor with Saxon version=Saxon-HE 9.6.0.9J from Saxonica

Test testXPathSingle:
C++: In SaxonProcessor::parseXmlFromString()
C++: SaxonProcessor* = 0xf20b90
C++: environ = 0xf1f7d0
C++: In XdmItem::size()
C++: XdmItem* = 0x124ef90
Number of items=1
C++: In XdmItem::getStringValue()
C++: SaxonProcessor* = 0xf20b90
C++: SaxonProcessor* = 0xf20b90
C++: In SaxonProcessor::getStringValue()
C++: SaxonProcessor* = 0xf20b90
C++: XdmItem* = 0x124ef90
C++: environ = 0xf1f7d0

Note the last line above, where the @environ@ variable holds a valid memory address. For the Python test, debug info below, that value is zero and, hence, the segmentation fault. The debug information without the "@C++:@" prefix comes from the Python interface.

In SaxonProcessor.__cinit__()
what = None
init = False
global _init = 1
C++: In SaxonProcessor::SaxonProcessor(bool l)
C++: l = 0
C++: refCount = 2
C++: before environ = 0x221c820
C++: SaxonProcessor* = 0x2d23cb0
SaxonProcessor* = 0x2d23cb0
In SaxonProcessor.newXPathProcessor()
SaxonProcessor* = 0x2d23cb0
before XPathProcessor* = (nil)
C++: In SaxonProcessor::newXPathProcessor()
C++: SaxonProcessor* = 0x2d23cb0
C++: environ = 0x221c820
after XPathProcessor* = 0x2c43810
In SaxonProcessor.parseXmlFromString()
SaxonProcessor* = 0x2d23cb0
before XdmNode* = (nil)
C++: In SaxonProcessor::parseXmlFromString()
C++: SaxonProcessor* = 0x2d23cb0
C++: environ = 0x221c820
after XdmNode* = 0x2e1fad0
In XPathProcessor.setContextItem()
XPathProcessor* = 0x2c43810
XdmItem* = 0x2e1fad0
In XPathProcessor.evaluate_single()
XPathProcessor* = 0x2c43810
before XdmItem* = (nil)
after XdmItem* = 0x2e1fca0
In Item.size
XdmItem* = 0x2e1fca0
C++: In XdmItem::size()
C++: XdmItem* = 0x2e1fca0
In Item.getStringValue()
XdmItem* = 0x2e1fca0
SaxonProcessor* = 0x2d23cb0
C++: In XdmItem::getStringValue()
C++: SaxonProcessor* = 0x2d23cb0
C++: SaxonProcessor* = 0x2d23cb0
C++: In SaxonProcessor::getStringValue()
C++: SaxonProcessor* = 0x2d23cb0
C++: XdmItem* = 0x2e1fca0
C++: environ = 0

The SIGSEGV crash occurs after this. What is strange is that if I comment out the offending line of code, the correct @environ@'s value appears again when destroying that same SaxonProcessor object at the end of the Python test:

In SaxonProcessor.__dealloc__()
SaxonProcessor* = 0x2d23cb0
global _init = 1
Destroying C++ SaxonProcessor*
C++: In SaxonProcessor::~SaxonProcessor()
C++: SaxonProcessor* = 0x2d23cb0
C++: refCount = 2
C++: environ = 0x221c820
C++: Reducing refCount by one
C++: refCount = 1

Included is the @jet_err@ file.