Do i manually have to load the JCuda libraries and jar files?, i added them in my project build path!
Program just does nothing, it does not crash it just stops the execution. JCuda.initialize() is called from a 2nd thread since first thread holds gui. My program runs fine in eclipse.
I tried the following versions for my runnable jar without success:
[ol]
[li]place native libraries *.dll files in same directory as runnable jar
[/li]- works in eclipse
[li]place native libraries *.dll files in other directory referenced by windows environment path variable
[/li]- works in eclipse
[/ol]
Admittedly, I have not yet tried to create an executable JAR with native libraries (not only for JCuda, but for any lib using natives). I can try around a little this evening and tomorrow. I wonder why there should be no error message. Maybe a
man i feel sorry to bother you again, and i am very thankful for your help,
i stopped working and shut down my computer and two hours later i installed jdk 7 and on next project export, it finally works to find the dll’s. I have no idea why but i am fine now.
The program does not work due to some other strange reasons but it finds the native libraries and the cuda device so that problem is solved.
I doubt anyone can do something with this but the word stemming Algorithm class from this site: http://tartarus.org/martin/PorterStemmer/ causes a fatal error when running the program from the executable jar using 100 documents to cluster.
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000000295e1c8, pid=4352, tid=5108
#
# JRE version: 7.0-b147
# Java VM: Java HotSpot(TM) 64-Bit Server VM (21.0-b17 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# J cluster.cpu.tokenize.Stemmer.stem()V
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
#
I tried to cluster only 3 very small documents and the program works!
[ol]
[li]100 bigger documents dont work
[/li][li]3 very small ones work
[/li][li]5 bigger ones work for first 2 times, third time it crashes again. (all 3 runs are from same program start!)
[/li][/ol]
Good to hear that the JAR itself seems to work now.
For the other problem: It’s not entirely clear for me whether this now is a problem that refers to CUDA/JCuda, or whether the crash also happens when you are ONLY using the plain Java class from the website.
The error message itself is very common in general, since it is only an Access Violation that happened inside the VM. But two things are confusing me:
The message “Failed to write core dump”. I’ve never seen this before. although a websearch on this error message brings many results. But maybe this is not too important.
More interesting: It reports “cluster.cpu.tokenize.Stemmer.stem()V” as the problematic frame. This is a Java function. Usually, Access Violations are caused, for example, by passing ‘NULL’ pointers to native functions, or writing data outside of array bounds, but then the problematic frame should be a native function.
Unfortunately, it’s hard to debug this program remotely, by just reading the error message. Since Java 7 is not considered to be mature and stable: Did you have the chance to test it with a recent Java 6 version (like Java 6 update 27) ?
bye
Marco
EDIT: BTW, if it was a Heap Space problem, it should throw an OutOfMemoryError - but not an “Access Violoation” crash. The latter usually means that something really odd happened…
[QUOTE=Marco13]Good to hear that the JAR itself seems to work now.
Did you have the chance to test it with a recent Java 6 version (like Java 6 update 27) ?
.[/QUOTE]
I removed jre 7 and now i use jre 6.27 and it works fine.
Man great thanks :), so many obstacles with java which are just impossible to know.
are the linux and windows jar files interchangeable?, (os switch statement to load dll’s would be really cool ?)
so i dont need new project just to export it for linux
and on release people only need to put their native libraries next to the jar file
They are not interchangeable, of course, but the JAR automatically loads the appropriate library for the current Operation System. So if you put ALL natives into a visible directory, then it will load the Windows .DLLs on Windows, the Linux .SOs on Linux and so on…
„Not interchangeable“ should only mean that you can not load the .SO files on Windows, for example…
When you copy the DLLs and the SO files into the same directory (together with the JAR file) then it will load the DLL files on Windows and the SO files on linux. Actually, I could provide only one download that contains one JAR file, and the native libs for all Operating Systems (and maybe I will do so in future versions).
Or, in case this was your question: The JAR file for all versions is exactly the same. It just loads different native libs depending on the Operating System on which the JAR file is used. (This is basically done with the „LibUtils.java“ class)