-
Notifications
You must be signed in to change notification settings - Fork 29
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
Segfault/memory corruption after reading textures #78
Comments
Looking deeper, the The code as it stands in
I changed it to the following:
I'm not super pleased with how that offset list is constructed, but it seems to correctly index the requested texels. This accesses the texels from the bottom-left of the sampled quad. There might be some way to change this to not allocate the entire texture's worth of memory to do whatever sampling is required, but if there is it's beyond me in the moment. |
I think there was a misunderstanding about how So far, I haven't been able to find an alternative way to read slices of textures into There are ways to read sub-textures/individual pixels from frame buffers, but they have been abstracted away. Instead I patched
Edit 29/10/2024: |
I have the following shader code:
And then the following code is run in the main loop. This is kind of messy since i was in the process of implementing and testing the picking code --
depthTexture
andidTexture
are both made usingnewTexture2D
earlier, and are the size of the window.The code flow here is that when the vertex buffer for the picking function (
res
) is updated, the first branch of theif
is run, and then after that the second branch of theif
is run (until the camera moves). Usually it crashes on the initialrunPickingImage
call, although once I think it made it to a second go-around to just callcheckPickingImage
. I've gotten segfaults,malloc(): unaligned tcache chunk detected
, andcorrupted size vs. prev_size
so far.If I comment things out so that
runPickingImage
doesn't callcheckPickingImage
, andcheckPickingImage
isn't called in the main loop, the program doesn't crash.checkPickingImage
itself seems to run fine and return a coherent value, but doing some putStrLn debugging makes it seem like the program crashes on the next render action after the texture read. That might just be the next memory allocation; I don't really know.This seems similar to #48 in that their issue seemed to have something to do with texture reads also; I've tried looking at RenderDoc but I have no clue how to record a frame trace if the program also crashes on that frame.
The text was updated successfully, but these errors were encountered: