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

SIGSEGV in createDevice when using queuePriorities #2

Open
joscha-alisch opened this issue Nov 17, 2019 · 6 comments
Open

SIGSEGV in createDevice when using queuePriorities #2

joscha-alisch opened this issue Nov 17, 2019 · 6 comments

Comments

@joscha-alisch
Copy link

Hi Folks,

I believe there is a bug with the priorities float buffer allocation in vk.DeviceQueueCreateInfo.

When doing the following the creation of a logical device fails with a SIGSEGV:

val queue = vk.DeviceQueueCreateInfo {
    queueFamilyIndex = graphics
    queuePriority = 1.0f
}

Results in

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGSEGV (0xb) at pc=0x0000000122816a51, pid=88962, tid=0x0000000000000307
#
# JRE version: Java(TM) SE Runtime Environment (8.0_171-b11) (build 1.8.0_171-b11)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.171-b11 mixed mode bsd-amd64 compressed oops)
# Problematic frame:
# C  [libMoltenVK.dylib+0x56a51]

However, when I push the float buffer myself, everything works fine:

val queue = vk.DeviceQueueCreateInfo {
    queueFamilyIndex = graphics
    queuePriorities = stack.floats(1.0f)
}
@elect86
Copy link
Contributor

elect86 commented Nov 17, 2019

Hi joscha,

yeah, I also experienced lately those crashes. I wasnt getting any before.

I'm not sure exactly where the problem lies, however I'm going with another better approach: we keep everything on jvm until we have to interface the vulkan api natively. At that point we push all the jvm resources to the native memory-stack,

You can see it in action here.

I got the idea from playing with Swift, they implement a very similar concept with c strings: you are given a valid pointer to the underlaying char array which is assured to be valid for the whole closure/lambda.
Everything is on Swift side until you have to interface c.

I'm using that same project as lab, but once finished I'll port all the work back to vk², hopefully in a few days

If you have any feedback, I'm here

ps: I'm also testing type safety for a couple of flag masks, let's see how that plays out

@joscha-alisch
Copy link
Author

but once finished I'll port all the work back to vk²

Sounds good, looking forward to it 👍

I might push some PRs your way afterwards if it's fine. I've noticed some of the "convenience" functions missing where you don't have to deal with buffers yourself. But I'll wait until you've done that refactoring, it would probably be double the work otherwise :)

@elect86
Copy link
Contributor

elect86 commented Nov 27, 2019

Pushed, tmp branch

relevant:

  • everything on jvm side till the native api call
  • added some extensions functions on the MemoryStack to malloc/calloc primitives (default to size 1) and various buffers and plain pointers (also with nice build dsl, eg: stack.IntAdr(size) { init(it) } or stack.IntBuffer(size) { init(it) }
  • kool introduces now inline class primitive pointers, you can see them here for example. They implements accordingly get/set operators with the right offset based on the type of the pointer

I'm eager to gather feedbacks, I'll send you an invite for the PRs

@elect86
Copy link
Contributor

elect86 commented Nov 30, 2019

vk10 is complete (always tmp branch)

@joscha-alisch
Copy link
Author

Hi @elect86 , sorry didn't have a chance to take a look yet. Will hopefully get to it on the weekend!

@elect86
Copy link
Contributor

elect86 commented Mar 16, 2020

Hi @joscha-alisch, news?

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

2 participants