Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JRuby encounters hard failure in FFI script #4320

Closed
ghost opened this issue Nov 19, 2016 · 2 comments
Closed

JRuby encounters hard failure in FFI script #4320

ghost opened this issue Nov 19, 2016 · 2 comments

Comments

@ghost
Copy link

ghost commented Nov 19, 2016

Recently I have been resuming work on wrapping up the Vulkan API via RubyFFI for my own amusement. In order to test it, I've been putting together a "smoke-test" script to see if I can set up the environment successfully or now.

Environment details:

jruby 9.1.6.0 (2.3.1) 2016-11-09 0150a76 Java HotSpot(TM) 64-Bit Server VM 25.51-b03 on 1.8.0_51-b16 +indy +jit [mswin32-x86_64]

The script is available here. The relevant source code for the wrapper library (and various mixins used in the script) is here.

At line 123 in the script, reproduced below, the JVM encounters an error and crashes. As I am presently only able to develop against Vulkan on my main Windows 7 machine (my VMs don't seem to have compatible graphics devices and fail preliminary checking), it displays the application crash dialog and searches for a solution.

Code around Line 123

device_info = VkDeviceCreateInfo.new(
    sType: :VK_STRUCTURE_TYPE_DEVICE_CREATE_INFO,
    queueCreateInfoCount: 1,
    pQueueCreateInfos: queues.to_ptr,
    enabledExtensionCount: 0,
    enabledLayerCount: 0,
    pEnabledFeatures: features.to_ptr
)

It does not appear to be a segmentation fault or access violation (as I've gotten plenty of those getting this far, and each time it managed to produce a dump). What is interesting is that this time, it never does and there is no file detailing the fault encountered.

When executed with MRI, the script completes successfully. Below is the output from one of the test runs:

Example output

D:\git\hephaestus>ruby init_vulkan.rb
Loading ... OK
Creating application info ... #<Vulkan::VkApplicationInfo:0x00000000519d48> (align: 8; size: 48 bytes)
Creating context info ... #<Vulkan::VkInstanceCreateInfo:0x00000000518ee8> (align: 8; size: 64 bytes)
Initializing ... VK_SUCCESS: #<FFI::MemoryPointer address=0x00000002e9bf30 size=8>
Unwrapping instance: #<FFI::Pointer address=0x00000000348070>
Now polling devices ... found 1 devices
Retrieving device list ... VK_SUCCESS: #<FFI::MemoryPointer address=0x00000002e9bf90 size=8>
Listing devices ...
Device 0 ~ #<FFI::Pointer address=0x0000000397a640>
 => properties: #<Vulkan::VkPhysicalDeviceProperties:0x0000000050aac8> (align: 8; size: 312 bytes)
--- DETAILS ---
API Version:    0x400018
Driver Version: 0x5dd18000
Vendor ID:      0x10de
Device ID:      0x11c0
Device Name:    GTX 660
Using device #0: #<FFI::Pointer address=0x0000000397a640>
 => features: #<Vulkan::VkPhysicalDeviceFeatures:0x000000004f3da0>
Device has 2 queue families
Retrieving ... #<FFI::StructArray address=0x00000002ea2870 size=48>
 - family 0: #<Vulkan::VkQueueFamilyProperties:0x000000004f2ef0>
Selected: 0
Creating device queue info ... #<Vulkan::VkDeviceQueueCreateInfo:0x000000004f1438>
Creating device info ... #<Vulkan::VkDeviceCreateInfo:0x000000004ebdd0>
Creating logical device ... VK_SUCCESS, #<FFI::Pointer address=0x000000040ca900>
---- SUCCESS ----
Cleaning up ...
Goodbye.

Note:

I'm using a slight modification of the script, which replaces lines 1 and 2 with the following:

print 'Loading ... '
puts load('./vulkan.rb') ? 'OK' : 'ERROR'
load './lib/structs.rb' if RUBY_PLATFORM =~ /java/i and not Vulkan.const_defined? :VkApplicationInfo
include Vulkan
@ghost
Copy link
Author

ghost commented Nov 20, 2016

Screenshot provided:

JRuby output and windows error dialog

@ghost
Copy link
Author

ghost commented Dec 28, 2016

Source of the issue has been identified as ambiguity in the FFI documentation and Wiki, which resulted in improper usage of certain helper methods.

@ghost ghost closed this as completed Dec 28, 2016
@enebo enebo added this to the Invalid or Duplicate milestone Jan 10, 2017
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant