on i64, can't create the symbol vector options #28
Comments
|
TECO on Itanium is an interesting beast. I'm not sure if V8.4 shipped with the latest TECO images. I do know it works with the latest fixes though, as that's how I build it. They can be fetched from here: http://ftp.endlesssoftware.com.au/teco/teco32_tv_av/ There were a whole bunch of bugs in the AEST/TIE_I64 facilities that stuffed TECO around. I fixed a great number of them and ended up with something that actually runs (and at reasonable speed too). |
|
No luck, here, on a 8.4 I64 system ... this is with the vms supplied teco this is with the updated teco looks promising, but the include file wasn't found, so sorting takes so long? And also annoying when (using mmk and) teco loops/hangs a control+Y and For the moment I give up, because, even if I get this linked Java dumps on me Java tells me this is at SQLITE_SHR+50, whatever that means, I have no idea, yet. |
|
Hmm, I'll look into that. I'll be putting in some time to get my changes in and hopefully bring it forward a few versions. So, I'll check it out then. |
|
Take your time. The linker is my friend and I know how to create symbol vectors. But to show that this works, I don't need that shareable image at all: I can link sqlite into my jni. |
|
The problem which results in Java writing a process dump is not related to the symbol vector. It looks like there are problems in the sqlite vms mutex code. Analyzing the dump shows the accvio in or close to that mutex code and Java can't handle the exception, so the last chance handler is kicking in. The printed "Problematic frame" still makes no sense to me. I added some printfs to show what is called. But that is only a start: I need a better way to debug the code. And yes, I should report that to HP :-) |
|
Hi @hb--, Are you able to show the contents of the log file? Does it actually save anywhere? |
|
I re-created another log file, the PC is different, but I don't think it is really different. Java for some reasons mapped the jni at a different location, that's all. I like this: but here it is, anyway Oh, here the OS is iVMS! Maybe I should get in contact with Apple. |
|
Got it to work. For some reasons, I enabled SQLITE_DEBUG, which is not a good idea - at least as long as xMutexHeld and xMutexNotheld aren't implemented. The accvio was in mutex\sqlite3_mutex_held, where sqlite3GlobalConfig.mutex.xMutexHeld is called. Unfortunately I don't remember what problem I wanted to debug when I enabled SQLITE_DEBUG. :-( |
|
Ahh, there are some callbacks I didn't implement as they were only used for debugging. I'll create a fresh issue to add those in. Even if they are not necessary for day-to-day life, they would be useful in situations like this (rather than creating a red herring :-). If you;re happy with the solution I can close this off. |
|
Yes, the mystery about the "fatal error detected by the Java Runtime Environment" with the advice to "report this error to HP customer support" is solved. The initial problem, not being able to create the symbol vector on I64 is still there, at least on my side. And there should be some mms/mmk rules to automatically make a new symbol vector if the enabled features (in config.h) changed. As I could not create one and was too lazy to manually adjust it and having all the sqlite code in the jni has some advantages, too, I no longer use/used the shareable image. The first attempt to use it, with the symbol vector options from Alpha failed. This probably triggered me to set the SQLITE_DEBUG which made it worse. The shell links against the shareable, but - my fault - I didn't retest this debug feature with the shell. Getting Java to use the jni was my focus and that was/is a challenge by itself. But once I could step with the VMS debugger through the sqlite code, it was easy to find the cause of the accvio. |
|
Excellent! Well, leave this open then for me to fix the symbol vector builder. I am completely swamped with work till the 1st of March, but maybe the weekend after I will be able to look at this and a couple other SQLite issues. |
|
hs_err_pid111622.log ... guys.. any idea for the below error? A fatal error has been detected by the Java Runtime Environment:%SYSTEM-F-ACCVIO (0xc) at pc=6749300, pid=111622, tid=296006144JRE version: Java(TM) SE Runtime Environment (8.0) (build 1.8.0.03-vms-rc1)Java VM: Java HotSpot(TM) 64-Bit Server VM (25.51-b02 mixed mode OpenVMS-ia64 )Problematic frame:C [RDBJDBCMPSHR6473+0x480]Please report this error to HP customer support.--------------- T H R E A D --------------- Current thread (11836C00): JavaThread "JDBC LostExecTimer" [_thread_in_native, id=296006144, stack(119A6000,11A4A000)] siginfo:si_signo=(null): si_errno=error 9732, si_code=12 Top of Stack: (sp=11A48AE0) Instructions: (pc=6749300) Stack: [119A6000,11A4A000] |
|
This problem report is for Oracle Rdb. You may need to get in contact with Oracle. (The printed "Please report this error to HP customer support." is misleading.) You may want to check if you have the latest version: On the other hand if you want to use SQLite and JDBC on VMS, you may want to try sqlite-jdbc-3.14.1-vms-j8.jar from www.vms2linux.de. For the SQLite version from this site, www.vms2linux.de has only drivers for Java 6, which - as explained on that site - do not work with Java 8. |
|
Unfortunately... i am from oracle.. i have that error to be fixed for my customer... funny isn't?! |
|
Hmm, interesting... It shouldn't be difficult to find the source line with the accvio, because you have the linker map and the source listing. You have everything we don't have. OK, the shareable image may be compressed and you have to do some address arithmetic. Or look at the image layout in memory from SDA. Is this reproducible? Then you may even use the VMS debugger and debug your shareable image. You probably already found my example how to debug an JNI on VMS. The example is for Java 6, but it may help with Java 8 as well. |
|
Yes, i will try to debug on vms with that shareable image. Worth to check... And it is not reproducible, I'm checking your jni on vms to debug. I will update you once am done... Thank you very much for your input :) By the way , I am OpenVMS Guy .. less experience on Oracle RDB... But some I manage it :) Thank you... |
TECO on i64 seems to be sub-optimal, it seems to be at least very slow, or it is simply looping:
The text was updated successfully, but these errors were encountered: