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

[Sepp Stadelmann]

Hi Volker,

thanks for the offer.

you can catch down 

1. Turtoise a subversion client for a windows system or

     any other command line version of subversion clients and then

2. investigate a bit the source repository tree (url below for svnkit) tree then

3. do a list and a checkout of either the trunk or the latest tag versions

having a command line version then start as follow

go to your default directory where you want to place your root for i.e. the svn trunk sources

C:\ > svn info http://svn.svnkit.com/repos/svnkit/trunk

C:\ > svn list http://svn.svnkit.com/repos/svnkit/trunk

C:\ > svn info http://svn.svnkit.com/repos/svnkit/trunk trunk

the first informs you about the trunk, the second lists all files and paths without a download, the last on checksout and downlaods the tree from the trunk, creates and puts it into a directory you chose i.e. trunk.

Then you may build from sources. You ay also catch down abinary version but then I  cant tell you from where to get it.

There is one issue: some days ago (last year) I got a trunk and I have built it using ant -f build

Meanwhile, unknown to me right now, they have changed the way svnkit is built and they use gradle.

I dont know gradle yet but guess it prepares for a mavne build. So it migth be that you need to install maven .

maven does not yet run on OpenVMS, it is my next challeng too. to be clear; it runs to a greate degree. But as Plexus uses sorts of unix shell commands to fiddle and catch file attributes, we get for certain tasks or goals fatal build errors in maven when run on OpenVMS.  

4. RESOURCES

SVNKit Web Site: http://svnkit.com/
SVNKit Documentation: http://svnkit.com/documentation.html
SVNKit Wiki: https://wiki.svnkit.com/
SVNKit JavaDoc: http://svnkit.com/javadoc/

SVNKit Mailing List: http://svnkit.com/support.html
SVNKit Issues Tracker: http://svnkit.com/tracker/

SVNKit Continuous Build Server: https://teamcity.svnkit.com/

any more help as you help me :-)?

Sepp

[Ph Vouters]

Sepp and other contributors to this post,

Excellent news : I downloaded jsvn-src-0.8.tgz from http://freshmeat.net/projects/jsvn/ and this is pure Java with absolutely no JNA dependancy. I could $ ant "run". However, the '$ ant "run"' returns me a successfull build although they are compile-time (javac) warnings for always the same cause disserminated into various source files:

 warning: non-varargs call of varargs method with inexact argument type for l
ast parameter;
    [javac] cast to java.lang.Object for a varargs call
    [javac] cast to java.lang.Object[] for a non-varargs call and to suppress th
is warning
    [javac]             setCommand(MessageFormat.format(COMMAND, new String[]{re
vision, source, destination}));
    [javac]

and a run-time (java) execution failure:

run:
     [java] Exception in thread "main" java.lang.NoClassDefFoundError: Could not
 initialize class sun.awt.X11GraphicsEnvironment
     [java]     at java.lang.Class.forName0(Native Method)
     [java]     at java.lang.Class.forName(Class.java:169)
     [java]     at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(Grap
hicsEnvironment.java:68)
     [java]     at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:91)
     [java]     at java.lang.Class.forName0(Native Method)
     [java]     at java.lang.Class.forName(Class.java:169)
     [java]     at java.awt.Toolkit$2.run(Toolkit.java:837)
     [java]     at java.security.AccessController.doPrivileged(Native Method)
     [java]     at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:829)
     [java]     at sun.swing.SwingUtilities2$AATextInfo.getAATextInfo(SwingUtili
ties2.java:120)
     [java]     at javax.swing.plaf.metal.MetalLookAndFeel.initComponentDefaults
(MetalLookAndFeel.java:1556)
     [java]     at javax.swing.plaf.basic.BasicLookAndFeel.getDefaults(BasicLook
AndFeel.java:130)
     [java]     at javax.swing.plaf.metal.MetalLookAndFeel.getDefaults(MetalLook
AndFeel.java:1591)
     [java]     at javax.swing.UIManager.setLookAndFeel(UIManager.java:540)
     [java]     at javax.swing.UIManager.setLookAndFeel(UIManager.java:580)
     [java]     at com.alternatecomputing.jsvn.gui.Application.main(Application.
java:54)
     [java] Java Result: 1

Shall dig into these two problems more thoroughly.

Meanwhile, Sepp, can you contact me offline ? My email address is at http://vouters.dyndns.org/ Us two closely collaborating on this JSVN subject, I guess we'll find soon an acceptable solution to this problem.

Awaiting for Sepp's email.

Yours truly,

Philippe

[Dennis Handly]

>can you contact me offline? My email address is at ...

You do know you can send private messages to exchange email addresses.

[Ph Vouters]

Sepp,

Can you help me ? How may I quickly get into your problem ? What I do need is an URL link where I can get the full JSVN source kit from ? Once you give it to me, I may then be able to download this source kit onto my Linux system using an svn client, gzip tar the source directory on my Linux and then transfer the compressed source kit onto the OpenVMS system I have access to.and gunzip detar it there.

Can you contact me offline ? My email address is at http://vouters.dyndns.org/ I am quite positive about a possible solution for you because I know Toine for long and Toine's statement is very hopeful. In consequence, I make no doubt that if Toine states JSVN runs successfully on his side, JSVN will run successfully on your side. That's just a matter of digging into the problem and close collaboration between you and me along with other good willing people who posted their replies..

Philippe

[Ph Vouters]

Dear repliers to this note,

I made tests tonight using the binary JNA SVNKit version kit found at http://svnkit.com/download.php. All my tests succeeded. I did not have to specify any Web proxy and ran with all SVNKit defaults. As Sepp indicates a timeout problem with JDK 6.0 and an aborted  partial transfer, I suggested him to first have a look at his VMS TCP/IP settings using:

$ @sys$manager:tcpip$define_commands

$ sysconfig -q inet

Also I suggested him to take a network trace using the command:

$ tcpdump -w foo.cap -p -s 1500 -vvv tcp port 8080

Port 8080 is because the communication goes through a proxy server using port 8080.

He can then comfortably analyze the produced binary data file (here foo.cap) onto either a Linux or a Windows computer using Wireshark.

Another test he may do is to install or use a JDK V6.x onto a Windows or Linux computer behind his Web proxy server, reissue the jsvn command from there and see whether he does or not reproduce the problem. If he does reproduce, this will orient the problem to the quality and reliability of the Web proxy.

A last remark I can make : I used SVNKit version 1.3.5 whereas Sepp uses SVNKit version 1.4.0.

Regards,

Philippe

[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