Std::sqrt crashes VCV rack

I wrote module in separate file “s1.cpp” When I use sqrt() func in this module VCV rack instantly crashes after add module

template <>
float String_v1<float>::force_calc (element left, element center, float l){

    float d_l=10;
    float h = (center.h-left.h);
    d_l = (float)((float)(h*h)+(float)(l*l));
    d_l = sqrt(d_l)-l;
    float f = d_l*left.k;
    if(center.h>left.h)
        f=-f;
    return f;
}

but then I comment line with sqrt() like this, it works fine

template <>
float String_v1<float>::force_calc (element left, element center, float l){

    float d_l=10;
    float h = (center.h-left.h);
    d_l = (float)((float)(h*h)+(float)(l*l));
    //d_l = sqrt(d_l)-l;
    float f = d_l*left.k;
    if(center.h>left.h)
        f=-f;
    return f;
}

Also, when I try to use sqrt() in process() in vcv_string.cpp it works fine too

outputs[AUDIO_OUTPUT].setVoltage(5.f * sqrt(sine)); 

Use ``` to surround code and terminal output. Post a stack trace of the crash.

[0.002 info src/main.cpp:113] VCV Rack v1.1.3
[0.002 info src/main.cpp:114] Windows 6.1
[0.002 info src/main.cpp:120] Args: C:\Program Files\VCV\Rack\Rack.exe 
[0.002 info src/main.cpp:123] System directory: C:\PROGRA~1\VCV\Rack
[0.002 info src/main.cpp:124] User directory: C:\Users\Olivier\DOCUME~1/Rack
[0.002 info src/settings.cpp:213] Loading settings C:\Users\Olivier\DOCUME~1/Rack/settings-v1.json
[0.003 info src/main.cpp:146] Initializing environment
[0.029 info src/plugin.cpp:157] Loaded plugin Core v1.1.3 from 
[0.194 info src/plugin.cpp:157] Loaded plugin Fundamental v1.3.1 from C:\Users\Olivier\DOCUME~1/Rack/plugins-v1/Fundamental
[0.195 info src/bridge.cpp:382] Bridge server started
[0.353 info src/main.cpp:161] Initializing app
[0.699 fatal src/main.cpp:38] Fatal signal 11. Stack trace:
22: ZN4rack10appDestroyEv 0x456415
21: gai_strerrorW 0x757ac0
20: _C_specific_handler 0x7766850c
19: RtlDecodePointer 0x77679c50
18: RtlUnwindEx 0x776685f0
17: KiUserExceptionDispatcher 0x776a124a
16: DrvSwapBuffers 0x6903d180
15: DrvValidateVersion 0x6903c5e0
14: wglSwapMultipleBuffers 0xfaf76a50
13: wglSwapMultipleBuffers 0xfaf76a50
12: wglDescribePixelFormat 0xfaf8a850
11: wglChoosePixelFormat 0xfaf89bb0
10: ChoosePixelFormat 0xff5e981c
9: glfwInitWGL 0x4dacb0
8: glfwPlatformCreateWindow 0x4d8814
7: glfwCreateWindow 0x4d1594
6: ZN4rack6WindowC1Ev 0x45afbc
5: ZN4rack3App4initEv 0x456160
4: main 0x7a0000
3: main 0x7a0000
2: main 0x7a0000
1: BaseThreadInitThunk 0x76f86520
0: RtlUserThreadStart 0x7767c500

Dumb question: could the number be negative?

No, because this the length of the hypotenuse.

Oh, right, couldn’t be negative.

It’s crashing when Rack calls glfwCreateWindow. Seems entirely unrelated to std::sqrt. (Btw, you’re forgetting the std when you call sqrt.)

Change to std::sqrt(). Still crashes

template <>
float String_v1<float>::force_calc (element left, element center, float l){
	
    float d_l=-10;
    float h = (center.h-left.h);
    d_l = (float)((float)(h*h)+(float)(l*l));
    
	d_l = std::sqrt(d_l)-l;
	
    float f = d_l*left.k;
    if(center.h>left.h)
        f=-f;
    return f;
    
}

Add func for exclude NaN and infinities. Still crashes

inline float inf_clamp(float x){ 
return std::isfinite(x) ? x : 0.f; }

template <>
float String_v1<float>::force_calc (element left, element center, float l){
	
    float d_l=-10;
    float h = (center.h-left.h);
    d_l = (float)((float)(h*h)+(float)(l*l));
    d_l = inf_clamp(d_l);
	d_l = std::sqrt(d_l)-l;
	
    float f = d_l*left.k;
    if(center.h>left.h)
        f=-f;
    return inf_clamp(f);
}

I noticed strange thing. If I add my module in new patch, VCV rack crashes and log.txt do not have stack trace. If patch with my module loads instantly after start VCV rack, log.txt does have stack trace.

At now I find next points.

  1. When using func frexp(x, &exp) this crashes too
  2. I set flags for compiler
FLAGS += -O0 -march=nocona

and my plugin stop crashes VCV Rack

You keep saying that Rack crashes when you add certain code, but what are you able to do to make Rack not crash? Debugging is not a matter of absolute results but a matter of delta-results, or changes to behavior given a controlled change to input. Can you rule out the result being probabilistic by verifying that the stack trace is the same across many similar experiments?

1 Like

My guess: At some earlier point, a function returned a pointer to a variable on the stack. Later, when you call sqrt(), the sqrt() function writes to that stack space, so the variable is no longer valid. If you don’t call sqrt(), the variable doesn’t get stepped on (yet).

2 Likes