JET Runtime Errors

[mhchristensen]

Been running into this error several times which is crashing the entire application:

JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR: runtime error
FATAL ERROR in native method: JNI DeleteLocalRef : tried to delete non local reference
Please, contact the vendor of the application.
Extra information about error is saved in the "jet_err_9084.txt" file.

JET RUNTIME HAS DETECTED UNRECOVERABLE ERROR: runtime error
FATAL ERROR in native method: JNI DeleteLocalRef : tried to delete non local reference
Please, contact the vendor of the application.

PID 8956, TID 13684

Version Information:

  Java version: 1.7.0_55
  Excelsior JET 9.00 Professional edition
  JET Profile: Java SE version: 1.7.0_55; JET update level: 12; CPU architecture: x86
  Runtime: Desktop
  Application was deployed

Options and system properties:

  -Djet.jit.disable.resolution=
  -Djet.gc.heaplimit=0
  -Djet.stack.trace=
  -Djet.remote.bundle.digest=309325d62a74921f7b03b0fedfb59cd96af433bd
  -Djet.remote.servers=http://www.saxonica.com/download
  -Djet.remote.bundle.name=libsaxon-HEC-detached-win-v0.3.1.pkl

Entry point type: Invocation API

Command line: "C:\Users\Michael Christensen\AppData\Roaming\nvm\v0.11.16\node.exe" --debug-brk=36798 --nolazy server.js

OS:

Windows 7 Service Pack 1 build 7601 [WOW64]

Process Modules:

0x01040000 - 0x01944000     C:\Users\Michael Christensen\AppData\Roaming\nvm\v0.11.16\node.exe
0x77740000 - 0x778c0000     C:\Windows\SysWOW64\ntdll.dll
0x75e80000 - 0x75f90000     C:\Windows\syswow64\kernel32.dll
0x75f90000 - 0x75fd7000     C:\Windows\syswow64\KERNELBASE.dll
0x75180000 - 0x751b5000     C:\Windows\syswow64\WS2_32.dll
0x75be0000 - 0x75c8c000     C:\Windows\syswow64\msvcrt.dll
0x75270000 - 0x75360000     C:\Windows\syswow64\RPCRT4.dll
0x750b0000 - 0x75110000     C:\Windows\syswow64\SspiCli.dll
0x750a0000 - 0x750ac000     C:\Windows\syswow64\CRYPTBASE.dll
0x76240000 - 0x76259000     C:\Windows\SysWOW64\sechost.dll
0x77710000 - 0x77716000     C:\Windows\syswow64\NSI.dll
0x75d50000 - 0x75e50000     C:\Windows\syswow64\USER32.dll
0x75af0000 - 0x75b80000     C:\Windows\syswow64\GDI32.dll
0x75990000 - 0x7599a000     C:\Windows\syswow64\LPK.dll
0x772a0000 - 0x7733d000     C:\Windows\syswow64\USP10.dll
0x75c90000 - 0x75d31000     C:\Windows\syswow64\ADVAPI32.dll
0x6d080000 - 0x6d0b2000     C:\Windows\system32\WINMM.dll
0x74ec0000 - 0x74edc000     C:\Windows\system32\IPHLPAPI.DLL
0x74eb0000 - 0x74eb7000     C:\Windows\system32\WINNSI.DLL
0x76f60000 - 0x76f65000     C:\Windows\syswow64\PSAPI.DLL
0x77240000 - 0x772a0000     C:\Windows\system32\IMM32.DLL
0x75fe0000 - 0x760ac000     C:\Windows\syswow64\MSCTF.dll
0x74de0000 - 0x74e1c000     C:\Windows\system32\mswsock.dll
0x74dd0000 - 0x74dd5000     C:\Windows\System32\wshtcpip.dll
0x74dc0000 - 0x74dc6000     C:\Windows\System32\wship6.dll
0x72f80000 - 0x72f97000     C:\Windows\system32\CRYPTSP.dll
0x72f40000 - 0x72f7b000     C:\Windows\system32\rsaenh.dll
0x0f930000 - 0x0f93b000     C:\Windows\system32\pcwum.DLL
0x74d90000 - 0x74d9d000     C:\Windows\system32\dhcpcsvc6.DLL
0x74da0000 - 0x74db2000     C:\Windows\system32\dhcpcsvc.DLL
0x748e0000 - 0x748f0000     C:\Windows\system32\NLAapi.dll
0x748d0000 - 0x748e0000     C:\Windows\system32\napinsp.dll
0x748b0000 - 0x748c2000     C:\Windows\system32\pnrpnsp.dll
0x74850000 - 0x7485d000     C:\Windows\system32\wshbth.dll
0x74d40000 - 0x74d84000     C:\Windows\system32\DNSAPI.dll
0x74840000 - 0x74848000     C:\Windows\System32\winrnr.dll
0x74810000 - 0x74837000     C:\Program Files (x86)\Common Files\Microsoft Shared\Windows Live\WLIDNSP.DLL
0x75b80000 - 0x75bd7000     C:\Windows\syswow64\SHLWAPI.dll
0x53340000 - 0x53358000     e:\ChristensenSolutions\SourceCode\Lantana\validator\node_modules\saxon-node\lib\binding\saxonXslt.node
0x0f3e0000 - 0x0f451000     C:\Windows\system32\MSVCP120.dll
0x0fda0000 - 0x0fe8e000     C:\Windows\system32\MSVCR120.dll
0x07500000 - 0x089b5000     C:\Program Files\Saxonica\SaxonHEC0.3.1\libsaxon.dll
0x76270000 - 0x76ebb000     C:\Windows\syswow64\SHELL32.DLL
0x67cc0000 - 0x67cfc000     C:\Windows\system32\pdh.dll
0x6dd80000 - 0x6dda1000     C:\Windows\system32\ntmarta.dll
0x75130000 - 0x75175000     C:\Windows\syswow64\WLDAP32.dll
0x003b0000 - 0x003b9000     C:\Windows\System32\perfos.dll
0x760b0000 - 0x7620c000     C:\Windows\syswow64\ole32.dll
0x50390000 - 0x5044e000     C:\Program Files\Saxonica\SaxonHEC0.3.1\rt\bin\msvcr100.dll
0x53370000 - 0x53376000     C:\Program Files\Saxonica\SaxonHEC0.3.1\rt\bin\jetvm\jvm.dll
0x53320000 - 0x53334000     C:\Program Files\Saxonica\SaxonHEC0.3.1\rt\bin\java.dll
0x53300000 - 0x53314000     C:\Program Files\Saxonica\SaxonHEC0.3.1\rt\bin\zip.dll

JET-compiled Components:

C:\Program Files\Saxonica\SaxonHEC0.3.1\libsaxon.dll dll, version info: jet-900-mp2 (pro, en)

Java Stack Trace: not available

[rimmartin]

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?

[mhchristensen]

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

xsltProcessor.compile(args.xsltPath);
xsltProcessor.xsltApplyStylesheet(args.xmlPath)
                     .toString()

The second pass since I had xml strings I used

xsltProcessor.compileString(args.xsltContent);
xsltProcessor.parseXmlString(args.xmlContent);

return xsltProcessor.xsltApplyStylesheet()
                                .toString();

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.

[rimmartin]

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

[rimmartin]

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

[seanmcilvenna]

@rimmartin have you figured anything out with this?

[rimmartin]

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

[rimmartin]

put try catches around on the native side but nothing caught by:

            try{
                xp->xsltProcessor->compile(*stylesheet);
                std::cout<<"exceptionOccurred "<<xp->xsltProcessor->exceptionOccurred()<<std::endl;
                if(xp->xsltProcessor->exceptionOccurred() || xp->xsltProcessor->exceptionCount()>0){
                    std::string errorMessage="# of "+std::to_string(xp->xsltProcessor->exceptionCount());
                    v8::Isolate::GetCurrent()->ThrowException(v8::Exception::SyntaxError(String::NewFromUtf8(v8::Isolate::GetCurrent(), errorMessage.c_str())));
                    args.GetReturnValue().SetUndefined();
                    return;

                }
            }
            catch(std::exception& ex){
                std::cout<<"std::exception "<<ex.what()<<std::endl;
            }
            catch(...){
                std::cout<<"compiled failed "<<std::endl;
            }

I see in the Saxon/C source calls the jet's env

bool SaxonProcessor::exceptionOccurred(){
    return env->ExceptionCheck();
}

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

Error 
  I/O error reported by XML parser processing
  /home/roger/NodeProjects/saxon-node/test/examples/xs/badbaz.xsl: No such file or directory
Exception in thread "main" net.sf.saxon.s9api.SaxonApiException: Failed to compile stylesheet. 1 error detected.
    at net.sf.saxon.option.cpp.XsltProcessorForCpp.xsltParseStylesheetFile(Unknown Source)
Caused by: net.sf.saxon.trans.XPathException: Failed to compile stylesheet. 1 error detected.
    ... 1 more
Error in compile

[ond1]

The forum seems dormant to me. The best way to contact Excelsior Jet is via
their support email

On Sat, Sep 5, 2015 at 3:08 AM, rimmartin notifications@github.com wrote:

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

—
Reply to this email directly or view it on GitHub
#7 (comment).

[ond1]

Hi,

Where are we with this issue?

Crashing of Saxon/C should not be happening. It would be good if I could
get a repo so that I can do some investigations at my end.

thanks regards
O'Neil

On Sat, Sep 5, 2015 at 3:40 AM, rimmartin notifications@github.com wrote:

put try catches around on the native side but nothing caught by:

        try{
            xp->xsltProcessor->compile(*stylesheet);
            std::cout<<"exceptionOccurred "<<xp->xsltProcessor->exceptionOccurred()<<std::endl;
            if(xp->xsltProcessor->exceptionOccurred() || xp->xsltProcessor->exceptionCount()>0){
                std::string errorMessage="# of "+std::to_string(xp->xsltProcessor->exceptionCount());
                v8::Isolate::GetCurrent()->ThrowException(v8::Exception::SyntaxError(String::NewFromUtf8(v8::Isolate::GetCurrent(), errorMessage.c_str())));
                args.GetReturnValue().SetUndefined();
                return;

            }
        }
        catch(std::exception& ex){
            std::cout<<"std::exception "<<ex.what()<<std::endl;
        }
        catch(...){
            std::cout<<"compiled failed "<<std::endl;
        }

I see in the Saxon/C source calls the jet's env

bool SaxonProcessor::exceptionOccurred(){
return env->ExceptionCheck();
}

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

Error
I/O error reported by XML parser processing
/home/roger/NodeProjects/saxon-node/test/examples/xs/badbaz.xsl: No such file or directory
Exception in thread "main" net.sf.saxon.s9api.SaxonApiException: Failed to compile stylesheet. 1 error detected.
at net.sf.saxon.option.cpp.XsltProcessorForCpp.xsltParseStylesheetFile(Unknown Source)
Caused by: net.sf.saxon.trans.XPathException: Failed to compile stylesheet. 1 error detected.
... 1 more
Error in compile

—
Reply to this email directly or view it on GitHub
#7 (comment).

[rimmartin]

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.

[rimmartin]

CentOS 5.x it is intermittent while running the exact same stylesheet and xml document

[seanmcilvenna]

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).

[rimmartin]

Trying to get a Excelsior Jet license to build on more OS's with the newest version to see if it fixes this