java1.4.2_08(b03)においてのプログラミング時、自身で書いたネイティブメソッド内でメモリリークが起きていて、不定期に落ちています。

過去の質問を見ると、ヒープとスタックをご存知ですね。

上記URLの解説を見るとメモリリークとは、

maloc()やnewした後でfree()やdeleteしていないことで、

これはヒープメモリのことです。

f_kennedy さんの認識はこちらのことですね。

バッファオーバーランと言う用語をよく聞くと思うのですが、

スタックメモリに関する障害はこれと同じようなことが起きています。

例えば以下のプログラムは環境によって動くかどうかは分かりません。

char * getstr()

{

　　char str[10];

　　strcpy(str, ”test”);

　　return str;

}

int main(int argc, char* argv[])

{

　　printf(”%s￥n”, getstr());

　　return 0;

}

解説:

str[10]はスタックにありますが、getstr()を抜けた時点で開放されます。

開放された領域のポインタを使ってprintf()しているので動作は不明。

ただし、開放したスタックもクリアされてはいないので動く可能性は有ります。

以上

(URLはダミーです)

「落ちる」原因が必ずしも「メモリリーク」とは限りません。OSやライブラリによって動作は違うと思いますが、たとえば NULL ポインターにアクセスした場合(char *p; と宣言された p が NULL の状態で *p = 0; などとして書くとUNIX系OSでは停止して core dump します)とか、malloc()/free() で既にfree()したポインタに対して再度free()した場合にも落ちることがあります。

その他、0による割り算とかメモリ確保した領域以外へのアクセスした場合、またそれによりメモリ管理のためのポインタが入っている領域を破壊した場合(これは次回のメモリ確保または開放時に落ちるかも知れません)。自動変数にスタックを使っているコンパイラ(現在のメジャーなコンパイラはだいたいはそうです)で元の関数へリターンするためのアドレスが入っている領域を破壊した場合(この場合 return 後に落ちる可能性があります)。あとUNIX系OSの場合、他のプロセスからの SIGABRT などのシグナル受信により core dump して落ちることがあります。(SIGTERM などは core dump しませんが停止はします)。

ということで、もし落ちた時に UNIX 系 OS のように core dump するのであればデバッガで停止した位置とそのとき使用していた変数の値などを確認することをおすすめします。

>ネイティブコード内部でメモリリークが発生していると、

>JavaVMがガベージコレクションを実行したときに、異常終了する恐れがあります。

だそうです。このページにあるSystem.gc()を利用したデバッグは実際有用でした。

URLはダミーです。

回答でなくて申し訳ないですが、まずどんなExceptionが発生しているのか、Exceptionが発生しているのがどういったコードなのか、といった情報があれば適切な回答ができると思います。例外をcatchしたところでprintStackTraceメソッドで表示させた内容を提示するのが早道と思います。

この質問の文章の範囲で答えると、メモリリークしているということはメモリの開放漏れを起こしている訳です。リークしたメモリというのはまだ開放されていない有効な領域ですから、そこを踏んだ (アクセスした) としても落ちたりはしません。メモリリークが原因で例外が発生するとしたら、メモリ不足例外でしょう。