Thread safety about fastnoise2 HOT 21 CLOSED

Thanks. In FastNoise_Config.h could you change #define FASTNOISE_USE_SHARED_PTR false to true will help determine if it's a SmartNode issue or something else

from fastnoise2.

There was a bug found in the thread safety of SmartNodes, the latest release (0.9.5) contains the fix for it

from fastnoise2.

There was a bug found in the thread safety of SmartNodes, the latest release (0.9.5) contains the fix for it

This happens with 0.9.5-alpha (from the release download)

from fastnoise2.

From your code above it looks like you are creating a new SmartNode per function call, ie no cross-thread access for a given node, is that true? or is the code above simplified?

from fastnoise2.

That's the function being called each time (it's just copy pasted directly.) There's an FFI boundary to get to that function, which I should have mentioned in the original ticket (sorry, just forgot to include it.) No cross thread access for a given node, or at least, there shouldn't be afaict.
The FFI code is basically this right now:

    // Setup an empty array filled with 0.0s
    let mut result =
        Vec::with_capacity(x_size as usize * y_size as usize);
    result.resize(result.capacity(), 0.0);
    // RAII mutex lock guard
    let _lock = MUTEX.lock();
    unsafe {
        // Calls the previously pasted function
        ffi::Generate2dNoise(
            x_offset.into(),
            y_offset.into(),
            x_size.into(),
            y_size.into(),
            seed.into(),
            octaves.into(),
            frequency,
            result.as_mut_ptr(),
        );
    }
    // Return the result / drop the mutex lock guard
    return result;

from fastnoise2.

If this is only showing up for me, I can try to repro it in just C++ later, but was curious if there were any known issues or anything

from fastnoise2.

Is your xSize * ySize < 8 it could be the same bug as #89 I'm working on a fix for it now

from fastnoise2.

They're all 32x32 (so xSize * ySize = 1024)

I'll see if I can come up with a better set of repro steps , but it also hasn't happened again today. (Maybe I missed clearing out some build artifacts from the old version? Or could just be some weird thing affecting a race condition? It did seem to happen more often when the rest of the app was running at higher framerates, for whatever reason) edit: it happened again today, just happening less often for whatever reason

from fastnoise2.

Can you see what line of code it is crashing on?

from fastnoise2.

It's hard to pinpoint exactly right now because can only get disassembly after it's linked etc, but it looks like it's somewhere in this:
GenUniformGrid2D or here
and then here: (from the assembly it seems like it's when the function returns? which seems weird)
OpenSimplex2 generator

from fastnoise2.

Could you show the assembly where it crashes? Can you get the crash on a debug build for more info?

from fastnoise2.

Yep! I'll see if I can setup the debug build etc, if I can't get that working I'll try setting up a purely C++ repro using the same compiler tooling etc later (probably won't have time this week for that one tho)

from fastnoise2.

Here's the disassembly! haven't seen it crash with a debug build yet, though: https://gist.github.com/jihiggins/164ed62dd843e59c736f5ba3b208d1cf#file-disassembly-asm-L48
(and one up in the callstack: https://gist.github.com/jihiggins/164ed62dd843e59c736f5ba3b208d1cf#file-disassembly-asm-L172)

from fastnoise2.

That's set, got a new crash from an assertion in debug mode.

First assertion:

https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Generator.h#L141
https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Fractal.h#L10
fnFractal->SetSource(fnSimplex); (from the first post)

If I continue, next assert is:

https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Generator.inl#L42
https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Generator.h#L143
https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Fractal.h#L10
fnFractal->SetSource(fnSimplex); (from the first post)

Then:

https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Generator.inl#L61
https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Fractal.inl#L24
https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Fractal.inl#L15
https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Generator.inl#L102

And finally, access violation here:

https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Generator.inl#L42
https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Fractal.inl#L24
https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Fractal.inl#L15
https://github.com/Auburn/FastNoise2/blob/v0.9.5-alpha/include/FastNoise/Generators/Generator.inl#L102

    fnFractal->GenUniformGrid2D(
            output, xOffset, yOffset, xSize, ySize, frequency, seed
    );

from fastnoise2.

(and then no problems next run, etc)

from fastnoise2.

Really weird that it only happens occasionally... in your code can you check that 'fnSimplex` is not nullptr. Did you try this?

In FastNoise_Config.h could you change #define FASTNOISE_USE_SHARED_PTR false to true will help determine if it's a SmartNode issue or something else

from fastnoise2.

Yep, this latest set of stuff is with that set to true. I'll add an assert for the fnSimplex check

from fastnoise2.

(Sorry in advance if this turns out to be some wonky FFI thing haha)

from fastnoise2.

I've ran into the exact same problem. I was able to partially track it down, for some reason dynamic_cast<VoidPtrStorageType>( base ); returns null in SetSourceSIMDPtr in Generator.inl. That's the reason of the crash. Unfortunately in my project I cannot debug it further as the problem does not occur in debug builds (likely due to the fact that debug builds run a lot slower) and the variables I'd need for debugging it get optimized out somehow (or at least don't load on breakpoints).

Either way for now I'm simply re-creating the base generator and re-setting the source in derived generators when simdGeneratorPtr is null. Works, but obviously far from ideal.

from fastnoise2.

That does sound weird. Are you sure the generator you are setting the source for and the source are both not null?

Can you show your workaround I'm not 100% sure what you mean

from fastnoise2.

It seems like with the latest release this problem doesn't happen anymore (afaict, I've had it running without the mutex for awhile now), so it's probably fine to just close out this issue :u

Thanks again!

from fastnoise2.