JET Runtime Errors #7
Comments
|
My experience with these occurring on linux in debug mode in netbeans in c++ projects. Or an attempt in a c++ thread. Second to this I was looking at the error messages and exceptions exposed by the Saxon/C interface and am testing implementing to see if they can be handled at xslt compile stage and transform xml stage. Do you have any idea of what stage yours occurred in? |
|
It didn't appear to happen in either from what I could see. I'll pay much closer attention if it happens again. I was doing schematron with no parameters. The first pass I called The second pass since I had xml strings I used As far as I could tell the transformations succeeded and the result was returned but alost immediately after my node process terminated with the error above. I have another error file that I compared in a diff tool and it was identical except for port numbs and process Ids. |
|
I'm getting these crashes for some unit tests under mocha runs. Which I didn't with older versions. In my c++ projects I see it happen steadily in debug mode running under netbeans. So it isn't specific to nodejs or saxon-node. Thinking to petition Excelsior for a free developer license for this project |
|
Fed broken xsl documents in but haven't seen the exceptionOccurred or exceptionCount return other than default false and 0. Want to test this outside of mocha runs with a small app |
|
@rimmartin have you figured anything out with this? |
|
I tried signing up to the Excelsior JET forums but didn't get a reply from them. I can ping them another way. I also see the problem when running redhat OS version 5.x; but not on OS 6.x. This is effecting a c++ project and they need stability too so I'm pressing that this coming week. http://www.saxonica.com/saxon-c/index.xml shows use of the jet version 9.0 MP2 while the jet website is at 10.5 stable. I'm wondering if it would produce a more stable run. Also I'd like to get a free developer license from them and build for more platforms/versions |
|
put try catches around on the native side but nothing caught by: I see in the Saxon/C source calls the jet's env but it appears the exception jumps right past this. Would be good to know if the jet version is supposed to have this implemented. And also what exception base is thrown for |
|
The forum seems dormant to me. The best way to contact Excelsior Jet is via On Sat, Sep 5, 2015 at 3:08 AM, rimmartin notifications@github.com wrote:
|
|
Hi, Where are we with this issue? Crashing of Saxon/C should not be happening. It would be good if I could thanks regards On Sat, Sep 5, 2015 at 3:40 AM, rimmartin notifications@github.com wrote:
|
|
It depends on which OS and version. I run stable on CentOS 6.x but not on CentOS 5.x with c++ only use[ no nodejs]. This week at work I'll gather more info on c++ only use. With nodejs it crashes when I run from mocha testing framework but not in my app. |
|
CentOS 5.x it is intermittent while running the exact same stylesheet and xml document |
|
In one Node.JS application, we are experiencing consistent successes... @mhchristensen experienced it ONCE in that application, while developing it. I have experienced it repeatably in another application. The first time saxon-node is used to transform with a stylesheet, it succeeds. Subsequent times, fails with the error referenced above/previously (and completely crashes the node app - try/catch does not help). |
|
Trying to get a Excelsior Jet license to build on more OS's with the newest version to see if it fixes this |
|
I find that if another jvm can be found in the environment first the crash happens. But when the has the jet libjvm.so first no runtime crashes unless the input is faulty[ this being the other problem with error handling] |
|
Interesting. I am keeping an tabs of this issue.
|
|
So, is this a build issue, or a runtime issue? I thought $SAXON_HOME is only required during build, which tells me the above is related to building with multiple JET libs... |
|
The JET libs are required at runtime
|
|
And I believe these are not packaged with the pre-built? |
|
hmm… I would say they are if I understand your question
|
|
Ok... so if the JET lib IS packaged with the pre-node-gyp package, then really the issue is that I am installing the pre-built on a machine that already has the JET lib, and there is a conflict between the JET lib installed as part of node-pre-gyp, and the JET lib that I already have installed? |
|
I think @rinmartin know best on how the pre-node-gyp package is setup.
|
|
prebuilts only store the saxonXslt.node compile. The jet and libsaxon.dll are onlyfrom the saxon/C package |
|
On windows the extra runtime environment might be What puzzles is why the jet err txt file spits out instead of the other jvm if it is getting picked up On windows when running mocha for unit tests i still see the crash; Pure c++ application runs now without crashing on CentOS 5 with the jet rt jvm on library path |
|
Still having this issue intermittently. Any update on this? |
|
@seanmcilvenna, @ond1 provided a new mysaxonhe.jar that worked with JET v11 on my ubuntu laptop. Tonight I'll get it on windows and fill an S3 bucket with OS releases. This should give us 64 bit windows as well. Then have to look more closely at exception and error handling tie in |
|
Hi @rimmartin, Do have the unit test case which fails with this error so that I can investigate it at my end. The exception looks like some JNI problem in Saxon/C. kind regards, O’Neil
|
|
Hi @ond1, it is intermittent. For me in a c++ only project it would only happen on a CentOS v5 OS but no on a CentOS v6. (I'll make a smaller test app we can use fr testing) Unless you have a CentOS v5 box you wouldn't see that particular one happen. And for @seanmcilvenna it might be particular windows version; I'm thinking to build for more OS's and see if it then stabilizes on them. For non-mac OS's I can build on different OS's on Amazon than I have of my own. |
|
Hi @rimmartin, It sounds like some memory corruption, but I will confirm that after receiving a repo from yourself. I have been doing a significant amount of work on Saxon/C in the last month or so, trying to push for a new major release. Many bug have been fixed and we have made overhaul changes to the API. I am wondering if it is ok to send you a pre-release so that you can make necessary changes in your saxon-node interface and report any problems from your testing. I think this might be useful to us. kind regards, O'Neil
|
|
Hi @ond1, I'd be happy to work with and test a pre-release. You have my work email for such communications. Building a small c++ only case to experiment with. Then for testing from node I can provide some scripts This is great news! |
|
One thing I noticed that is wrong in the compile method of XsltProcessor is if the stylesheet compilation fails we call checkException and then exit. We definitely should not be calling exit(0). This means we cannot recover from the exception and that is probably why Jet is intercepting the crash and producing the crash report file. In the latest release I have resolved this issue. As a workaround please try commenting out the following lines in the compile method of the XsltProcessor class and let me know if it makes a difference: if(!stylesheetObject) {
|
|
One way I can make it fail is load up the cpu's to 100% on a 32 cpu CentOS 6 box and then run rhel4saxonapp main for 500 reps |
|
The new Saxon/C release is using a new jet; testing it this week |
|
Running the following PHP code: Using the latest version, on Ubuntu 14.04 LTS. $validator->registerSchemaFromString("<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' elementFormDefault='qualified' attributeFormDefault='unqualified'><xs:element name='request'>xs:complexTypexs:sequence<xs:element name='a' type='xs:string'/><xs:element name='b' type='xs:string'/>/xs:sequence<xs:assert test='count(child::node()) = 3'/>/xs:complexType/xs:element/xs:schema"); JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR: system exception at 0x00007f851edf0108 Signal 11 (SIGSEGV) PID 4782, TID 0x00007f853f086780 Registers: RAX = 0x0000000000000000 Stack: 0x00007fff45246e70: 0x00007f8540ca0c89 0x00007f8529fbcba6 JET-compiled Components: /usr/lib/rt/jetrt/libXKRN11008065.so dll, version info: work installation, jet-1100-mp1 (Fri Dec 04 01:01:44 ALMT 2015) Java Stack Trace: not available |
|
Hi @WillMac29, This segmentation fail error is being intercepted by Jet. The root cause is probably Saxon/C trying to re-initialize the Jet JVM. Jet prevents JVM initialisation in the same process. I have addressed this problem in the bug issue: https://saxonica.plan.io/issues/2670 https://saxonica.plan.io/issues/2670 kind regards, O'Neil
|
|
Thanks @ond1! I will attempt to install it again from scratch and double check my steps, and once again when the maintenance release is available. My phpInfo() had all the associated Saxon entries present, but it was failing on line 3. $proc = new Saxon\SaxonProcessor(true); |
|
Hi @WillMac29, Have you installed a saxon license?
|
|
Hey @ond1. My mistake. I provided the wrong code before. I am not using a commercial licensed version. I am using Saxon-HE/C (open source). Do I still need a license? http://www.saxonica.com/saxon-c/libsaxon-HEC-setup64-v1.0.0.zip $proc = new Saxon\SaxonProcessor(); Error: Processor is not licensed for schema processing! Fatal error: Call to a member function registerSchemaFromString() on null in /home/will/Code/canadastays-v5/app/Console/Commands/Feeds/OwnerDirect/schema.php on line 5 Call Stack: |
|
Hi @WillMac29, Schema Validation requires a license and you will need to download the commercial product Saxon-EE/C. A license can be purchased from our website: http://www.saxonica.com/purchase/purchase.xml http://www.saxonica.com/purchase/purchase.xml. You can also get a 30 day evaluation license at http://www.saxonica.com/download/download.xml http://www.saxonica.com/download/download.xml kind regards, O'Neil
|
|
In the situation where a SchemaValidator cannot be created for reasons of missing license file, or wrong product used we need to provide better diagnostics informing the user of the problem and therefore to avoid seg error later on when the SchemaValidator object is used. I have added this as a bug issue to be added in the next maintenance release: https://saxonica.plan.io/issues/2706 |
|
Ah good! |
Been running into this error several times which is crashing the entire application:
The text was updated successfully, but these errors were encountered: