When using JOCL, e.g., by running the JOCL demos (versions 2.1.1 and 2.1.2), with a 32 bit jvm on windows, the vm crashes. This is a regression introduced in 2.1.1. It works with JOCL 2.1.0. The issue does not occur when running with a 64 bit jvm. This suggests a problem in the 32 bit dll. The issue also does not occur on linux. We cannot revert to version 2.1.0 as in this version there are issues with getting JOGL running with the latest NVIDIA drivers. Hence it's blocking to us. Would it be possible to fix the JOCL 32 bit windows dll for version 2.1.2? Thanks!
Created attachment 565 [details] vm crash error log
Hi Please can you try with some builds between the 2.1.0 and 2.1.1? I don't see which commit might have caused this regression.
Maybe it comes from this commit: https://github.com/sgothel/jocl/commit/6be41a8e457ec2881f4ce351395ba84748a737b6 I suspect this line: https://github.com/sgothel/jocl/blob/6be41a8e457ec2881f4ce351395ba84748a737b6/src/com/jogamp/opencl/llb/impl/CLDynamicLibraryBundleInfo.java#L136 The address should be an int, not a long but I don't understand why you don't reproduce this problem under Linux 32 bits. Maybe I'm completely wrong.
(In reply to comment #3) > Maybe it comes from this commit: > https://github.com/sgothel/jocl/commit/ > 6be41a8e457ec2881f4ce351395ba84748a737b6 > > I suspect this line: > https://github.com/sgothel/jocl/blob/ > 6be41a8e457ec2881f4ce351395ba84748a737b6/src/com/jogamp/opencl/llb/impl/ > CLDynamicLibraryBundleInfo.java#L136 > > The address should be an int, not a long but I don't understand why you > don't reproduce this problem under Linux 32 bits. Maybe I'm completely wrong. All native address data are handled as int64_t/long in java, since this is the [opaque] common denominator. (Used in JOAL, JOGL, ..)
(In reply to comment #4) > All native address data are handled as int64_t/long in java, since this > is the [opaque] common denominator. > (Used in JOAL, JOGL, ..) Thank you for this explanation.
Another user seems to have seen this bug -- see http://forum.jogamp.org/Error-while-runing-clinfo-jnlp-with-Intel-HD-4000-td4031425.html. There seems to be something wrong with the address it's trying to jump to for the clGetExtensionFunctionAddress() function. After dispatch_clGetExtensionFunctionAddressStatic() the execution never ends up inside IntelOpenCL32.dll, instead it hits the native Java_com_jogamp_opencl_llb_impl_CLAbstractImpl_dispatch_1clGetExtensionFunctionAddressStatic(), then crashes when it tries to jump to the function pointer.
569726132f622e290bebc5d40c96f8115dbcb5da Fix Bug 920 - JOCL does not work on windows with 32 bit vm (1/2) The 'clGetExtensionFunctionAddress' function pointer declaration was faulty, i.e. using CL_API_ENTRY instead of CL_API_CALL. CL_API_CALL on windows is defined as '__stdcall' which impacts Window 32bit platforms. Fixed same issue w/: - clCreateContext - clBuildProgram Same issue occurs with _all_ gluegen generated native function wrappers, i.e. CL_API_CALL is missing in the function declarations! I will follow-up w/ this fix in a bit ..
aeb5cb8f1de47841cca328227faff0d4ccbb97c5 Fix Bug 920 - JOCL does not work on windows with 32 bit vm (2/2) All gluegen generated native function wrappers, miss CL_API_CALL in the function declarations similar to commit 569726132f622e290bebc5d40c96f8115dbcb5da. Adding gluegen calling convention to cl-impl.cfg: LocalProcAddressCallingConvention __ALL__ CL_API_CALL All tests passed on windows 32bit now!