JDK 1.5.0 & JDK 6.0 JVM crash executing JSVN, a Java Apps

[Ph Vouters]

Dear Sepp,

In short, these are the conclusions I can withdraw from my JSVN tests:

http://vouters.dyndns.org/tima/OpenVMS-Java-Subversion-SVNKit-Using_a_Subversion_Java_based_client_on_OpenVMS.html

Yours truly,

Philippe

[Volker Halle]

Philippe,

great article. Thanks.

Did you see the ACCVIOs as seen by Sepp in your testing ? As a 'true OpenVMS engineer', you would want to reproduce the erros, which Sepp has reported and dig down to find the real problem or create a reproducer, so there is a chance for HP to solve the 'real problem' - assuming it is in HP code.

Just a suggestion.

Volker.

[Sepp Stadelmann]

Thanks Volker

Thanks Philippe

The lucky mens do not have the same problem as I have. Particular there are other lucky guys in HP OpenVMS Engineering in India. They said to me that I must just patch the system. Now we did so, and OVMS 8.3-1H1 and 8.4 is patched as shown in a previous replys of this topic.

BUT jsvn does just not run on my OpenVMS

Unfortunately it does not run on our

a) rx2660 OpenVMS 8.3-1H1  / JAVA 1.5.0-5 and it does not run on

b) rx2800 i2 OpenVMS 8.4       / JAVA 1.5.0-5 and JAVA 1.6.0-p1

NOW ...

starting jsvn checkout ...  using JAVA_DBG shows me a Debugger

How can you do this.

edit your [.^.svnkit_1.3.5.7406]jsvnsetup.openvms command file add basically 2 lines

$ JV = f$edit(java,"collapse")
$ JVD = f$edit(java_dbg,"collapse")
$ jsvn ==      "''JV' ''OPT' -cp ''CP' ""org.tmatesoft.svn.cli.svn.SVN"""
$ jsvnd ==      "''JVD' ''OPT' -cp ''CP' ""org.tmatesoft.svn.cli.svn.SVN"""

Then execute

$ jsvnd checkout <url> trunk

and see how the debugger opens an Xwindow or prompts in terminal mode

then do a

DBG> set module /all

DBG> set image /all

DBG> set break exception

DBG> go

DBG> go

and then get happy with all those unhandeled exceptions in underlaying libraries.

just press go for ever;

you will see that jsvn will work and continue to work and transfer files even you migth get the impression that it should terminate. Maybe aftzer a while if you are one of the lucky guys it will run to its end; if you are unlucky as I am it starts getting wors. just hit go and it recovers sometimes or it may fail.

But you then know after all this "somehow and somewhere there is a problem".

You know it for sure if it does not transfer all of the repository files. 

Stack corruption may lead to very varying problems, particular if exceptions are not or badly handled.

If you don't have this exception then please tell me and pass to me the

DBG> show image *

DBG> show module *

what else --- unfortunatly I do not have sources --- hence it is a HP issue next

Josef

[H.Becker]

>>>Stack corruption may lead to very varying problems, ... <<< True, but this is not a stack corruption, it is a heap corruption. >>> ...particular if exceptions are not or badly handled. <<< The exception - ACCVIO - you experience can't be handled by user/rtl code. As already shown, one of the bad VAs looks like the string "SYSTEM". There is no chance to correctly handle such a bad VA. (The flood of exceptions, KEYNOTFOU and ACTIMAGE, is just a result of dynamically activating images, that is using lib$fis which here is very likely called from dlopen. I'm sure it is possible to set a break point after all the activations are done and then set the break/exception: piece of Schwarzwaelder Kirschtorte.) >>>what else --- unfortunatly I do not have sources --- hence it is a HP issue next <<< True. Maybe some people have the listings for the librtl and for decc$share. But I doubt that the VMS Java listings are on the VMS listings CD, the one you can buy. But, whoever has access to all these listings should be able to analyze the process dump and to get (closer) to the root of the problem - in a couple of hours. Anybody else can just fish for compliments, ahem points, ahem kudos. That said, I have a notebook and can travel. Trains go from Munich to Winterthur several times per day and I am willing to accept CHF for any analysis, reproducer, investigation, etc. :-) But, as already said, I would not spend anything (including EURs) on this and just use svn or jsvn from any other operating system to check out the sources.

[Ph Vouters]

For repliers to this post knowledge of what was happening,

While executing his up to date java$java.exe code under the VMS
debugger, the code sequence for the Java ACCVIO was C RTL stat calling
xstat calling C RTL something like decc$free_fcb or decc$deallocate_fcb
(sure a routine name containing fcb), calling C RTL free, calling
LIB$FREE_VM where the ACCVIO occured.

As the DECC$SHR.EXE and java$java.exe I FTP'ed him have been getting an
unreproducible on my side FileNotFoundException on a specific file which
is indeed created by the JSVN command, this drove me to focus my
attention onto files/directories operations on his computer. As well,
his ~/.subversion directory was not getting automatically created and
populated despite no acceptable reason.

Hence my thoughts driving me to focus my contact's attention onto his
error log and that he especially focus onto any disk error report.
When I told him I was suspecting anomalies with his VMS filesystem
activity, he reported me he was experiencing problems with some other
non Java related software such as backup (if my memory does not betray me).

My conclusion for you : there may well be a call logged at HP but likely
for hardware reasons.

With my very best regards to you, 

[Ph Vouters]

For those interested with,

Following this work onto Sepp's problem and my co-work with him,I did modify my already mentioned article at

http://vouters.dyndns.org/tima/OpenVMS-Java-Subversion-SVNKit-Using_a_Subversion_Java_based_client_on_OpenVMS.html . My purpose has been ito make  it even clearer and really helpful to future readers.

On my way working onto Sepp's problem, I added the following work related articles to my knowledge database :

http://vouters.dyndns.org/tima/OpenVMS-Java-V6.0-jar_returning_a_no_such_file_or_directory.html

and

http://vouters.dyndns.org/tima/All-OS-Differentiating_software_and_hardware_problems-Some_hints.html

Providing some of you have remarks to make, there are best addressed to my private mailbox you'll find the coordinates at http://vouters.dyndns.org/ Any feedback is very welcomed as long as it may serve the worldwide IT community looking after solutions by querying public Web search engines. With the Web traffic I do observe, this may also help HP employees to even better serve you with your use of HP products.

Philippe Vouters

[Sepp Stadelmann]

I like to thank Philippe for his excellent help. Joint we could isolate the problem but not fix it. The fix must be done by HP.

OpenVMS 8.3-1H1 and OpenVMS 8.4 each with either

JDK 1.5.0-5 or JDK 6.0-p2 setup both had the same very bad symptom.

In short, the svn subversion kit (svnkit) command 

$ jsvn checkout <url-to-repository>/trunk  trunk

was not running but the JVM crashed at random points during the transfer

After all the wrok it runs now on all our machins in all configurations to a successfull end and we can download sources from remote repositories such as axis2 or maven straigth to OpenVMS systems.

The problem is not yet fixed, just isolated and should be closer investigated and fixed by HP OpenVMS Engineering.

To get JSVN CHECKOUT run we did a

$ deassign JAVA$RENAME_ALL_VERSIONS

And then it runs fine.

This logical is the reason why HP OpenVMS Engineering always reported to me that it is running at their site and we would have only to  patch our system. They did never define this logical, and it is not defined by default JAVA$SETUP.COM

But patching allone to the last ECO did not make it any better.

The core problem still exists and needs to be fixed by source code owners or else you add a time bomb and buy in a potentially crashing JVM as soon as you define JAVA$RENAME_ALL_VERSION.

Josef