実行GのABENDに関する考察
CEEDUMPを吐いて、WMBの実行GがABENDという状況。
JOBLOGを見るとJavaのスレッドでStackOverFlowError。
StackOverFlowErrorはたいがいアプリの問題。
しかし、結果的にABENDするのは何故だろうか。
CEEDUMPのTracebackからはesqlからjavaを読んでいるように見受けられる。
そもそもWMBはC++あたりの言語で書かれていて、
C++からJavaを読んでるという仕組みになっている。
つまりはJNIでJVMを作成して、あれやこれやしている。
自分はC++でJVMを動かすコードは書いたことはないけど、
JNIとして規定されているので、さほど難しいことには思えないけど。
CEEDUMPを見ると、getStringCharsというJNI関数が呼ばれ、
その先でz/OS固有っぽい関数が呼ばれている。
この2つの関数はJ9にライブラリに存在する。
例外はこのz/OS固有っぽい関数で発生している。
以下の例外がCEEDUMPに出ている。z/OS固有っぽいところで起きてるやつ。
CEE3204S
The system detected a protection exception (System Completion Code=0C4).
このメッセージは「Language Environment Run-Time Messages」に載っている。
気になるのは、例外発生中に、なんでgetStringCharsなんて呼んでるんだろうという点。
JNI仕様の「Exception Handling」の項目に書いてある部分。
ペンディング中の例外がある場合に安全に呼べるJNIはこれら。
ExceptionOccurred()
ExceptionDescribe()
ExceptionClear()
ExceptionCheck()
ReleaseStringChars()
ReleaseStringUTFChars()
ReleaseStringCritical()
Release
ReleasePrimitiveArrayCritical()
DeleteLocalRef()
DeleteGlobalRef()
DeleteWeakGlobalRef()
MonitorExit()
PushLocalFrame()
PopLocalFrame()
つまり、getStringCharsなんて呼んでていいのかってこと。
それともExceptionClearをちゃんと先に呼んでいるのだろうか？
で、この疑惑を受けて、esqlからjavaを呼び出した先で、
例外が起こった場合はどうなるかってのを調べるためだけの
簡素なアプリでも作ろうかなって思うわけだ。
あと、他に解析に有効な手段があまり無くて困ってる状況だが、
例えば-verbose:jniを仕込むのもアリかもしれん。
