Open nh2 opened 10 years ago
Hi Niklas, feel free to send a pull request, if you think it's a better name (maybe pick one not as harsh as the one you proposed ;) ). Otherwise I will close this one, as it's not a bug.
Hey Jochen, of course I was joking. The bug is that the size of the buffer should not be hardcoded in the first place.
The kernel should check whether the bound has been reached before writing to the buffer, so that at least we get an error message instead of a crash.
A better alternative would be growing the buffer as needed. I might try an implementation of that in a few weeks, and after I've pull requested my colour version of marching cubes.
:) +1 for a fix.
Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs.
Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs.
Form a quick search in the code, this issue remains unchanged.
Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs.
Please, this issue will not go away by time...
Bit of an unrealistic request after 6 years, but would you happen to still have any code that could reproduce this issue?
Marking this as stale due to 30 days of inactivity.
would you happen to still have any code that could reproduce this issue?
@haritha-j Why would that be necessary?
seems pretty clear about things being just as they were 6 years ago: Hardcoded buffer size, and no check in the code that the output will actually fit.
Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs.
pcl::gpu::MarchingCubes::run
:marching_cubes.cu
/store_point()
:I suggest changing
DEFAULT_TRIANGLES_BUFFER_SIZE
toWHY_WOULD_ANYONE_EVER_HAVE_MORE_TRIANGLES
, that will make the out of bounds crash on the GPU much easier to find.I also like how it starts with
2 *
- that looks almost like somebody thought "hmm for some reason the code works if I make this bigger".