So in my little terrain demo, I was trying to implement a simple method to shift the coordinates of the input so as to render different portions of the terrain map by simply pressing a button in the direction I'd like to shift it.
The problem is mapping the kernel again. No matter what it always crashes with a segmentation fault, it seems one for each of the arguments to the kernel.
This is how it goes down.
Initialize opengl, sdl, etc...
Run kernel outputting to a buffer in system memory, map the vertices and extrapolate color values into 2 VBOs.
heightmap = NULL;
Rendering now occurs peachy keen!
*Press button to shift the height map coordinates*
Reallocates the input and output buffers.
Prepares input buffer coordinates.
Enters the kernel again and attempts the map function.
Gets as far as... brook::CALContext:rawRectangle() calcontext.cpp:1243 0x00007f0e72792f92
Reports SIGSEGV / Symbol(s) not available:
Any ideas? Feel free to request more info on the problem I don't have a clue how to fix it as I've assured the pointers are all freed/NULL/reallocated as necessary, and it just seems the kernel is not recognizing the new memory locations for any of the input variables.
I just had the bright idea to try running the streamread/kernel/streamwrite commands twice in a row in order to determine when this problem crops up...
It actually only occurs once the function encompassing the brook kernel execution exits. This function allocates the input buffer, it used to allocate the output buffer but it only really needs to be done once for my current experiments, so I left it static. Now I've even insured that no buffer is initialized twice, and hence the input/ouput buffer pointers are essentially static locations in memory. It still doesn't work, and the opposite scenario of freeing the buffers and reallocating them is not working either.
So the issue seems to stand that upon exiting the function the first time
After essentially stripping it down and adding conditional statements to the function, I've made it so it essentially just calls streamread/kernel/streamwrite.
So whatever happens once the streams go out of scope must be the issue here.