I've got no idea what causes this crash. I've looked through the log and got nothing meaningful. Anyone cares to help please? :)

EDIT:
I've also attached the log in case someone spots something interesting. I tried cross-referencing it with objdump of JNITest and tried using addr2line as well, it gave me nothing good. A GDB session was also uneffective at determining the root cause.

/scratch/workareas/JTest/hs_err_pid14752.log what does this have in it?
–
Sid MalaniDec 16 '11 at 10:20

I've edited the opening post with an attached log. The error is supposedly somewhere in C, altho I don't really see where. The calls return OK as well so I'm not sure how this crash will affect this later - that's why I want to clear this issue before I start finishing the EventHandler.
–
SharkDec 16 '11 at 10:40

It also might be worthy to mention that this exact same behaviour displays with both Sun's JRE and openjdk as well. I pretty much ran out of options which is why i'm asking.
–
SharkDec 16 '11 at 10:42

Could you remove the printf statements in c and check if it works. printf("Calling dispatchEvent() [%p] ...\n", dispatchMessage); should perhaps be after the null check.
–
Sid MalaniDec 16 '11 at 10:44

I played around with those as well - removing the first printf or terminating it with \n causes the program to segfault. I'm guessing because the JVM doesn't have time to load and the printf is "blocking" it just enough for it to work ok. Moving the line 'printf("Calling dispatchEvent")' changes nothing; and it is used to print the pointer value of the dispatchEvent() methodID. I printed it to see if it's null or not, it's a debug message so moving it in the is-null if check defeats it's purpose.
–
SharkDec 16 '11 at 10:53

2 Answers
2

Near the bottom of it is a nice example of both how to pass multiple options AND how to name them. Turns out -Xcheck:jni is passed as -DXcheck:jni (jni:pedantic works too) and after I moved the strcpy out of my code, I no longer get the crash dump at the end. I suspect the culprit was strcpy but one of these did the trick.

For what it is worth, in situations like this one, running the JVM with -Xcheck:jni can sometimes spot what the eye is missing.

Edit: and I don't see anything obvious here either.

I suspect the culprit was strcpy but one of these did the trick.

The reason your strcpy made it crash is that the JavaVMOption just contains a pointer to a string, when you assign your string you make it point to the constant option string, when you strcpy something to it your are basically writing things to a pointer you have not allocated. I didn't even think about looking at such errors when you first posted your question. Sorry.

So how do I pass the Xcheck:jni:pedantic option to the VM? Editing the optionString and nOptions didn't work, guess I'll dig out how to do it in the meantime if you don't beat me to it :)
–
SharkDec 16 '11 at 12:28

Like any other option, it is not a -D thing though... It should be: "options[1].optionString = "-Xcheck:jni";
–
FredrikDec 16 '11 at 13:12

turns out either way is fine since I found the root cause. Thanks for the heads-up though.
–
SharkDec 16 '11 at 14:06

1

@Shark ">turns out either way is fine"... Well, one instructs the JVM to check for faulty references and other JNI errors, the other one just add a system property. Big difference.
–
FredrikDec 16 '11 at 14:18

I understand the 'Big difference' but whether it's on or off really brings nothing new to the table or affects the situation in any way.
–
SharkDec 16 '11 at 17:09