Looking for brave souls! (Ok, looking for testers :P)

Development
1

Tidal modulator has a floating point error bug that triggers under a very specific set of conditions, as described here:

I also noticed that the reason a few of us have encountered it or triggered it is, also, kinda moot: syncing Tidal modulator to a clock doesn’t really do much.

I used to be able to trigger the bug; but now I can’t, not after Windows’ patch tuesday.

Whatever the case might be, I created Aestus: clock sync is now a button (restores clock syncing AND bank selection when the module is in Sheep mode) and putting a clock signal in the “Clock” input actually syncs the module (takes a couple of seconds to adjust to your clock, as expected, and, needless to say, being user controlled, the module no longer automagically turns sync on when a cable is connected to the “Clock” port); puts the available options on the faceplate, and all my usual, controversial, stuff; but it would be nice to see if the module no longer crashes other people’s machines or I’m just having local, Windowsy fever dreams.

Sooo… if you’d like to test it (and enjoy it :)), grab the 2.5.0WIP nightly from the usual Mutants spot; play around with it, put a clock on it, turn sync on, off, remove the clock, play with the range button, reclock it, declockit, sync it, desync it… and… let me know how it goes :slight_smile:

Thanks :slight_smile:

1 Like
2

That bug sure looks like the denominator being zero.

3

But is it still present on my version?

4

2.5.0WIP crashed to deksktop for me (updated windows 11) sending random stuff to clock and trig and toggling “sync”. Nothing in the log - I will run it in a terminal later, when i get it built to see if something is written in developer mode.

  • sync on, click “frequency range” many times - no crash happens.

  • toggle sync button off and on.

  • Activate the frequency range button a few times. It changes the button color to red, and crashes. reproduced 5 times in a row, but sometimes it doesn’t crash when doing this procedure

    bloodbat-250WIPtest.vcv (2.9 KB)

2 Likes
5

I have not idea. did you change the line of code that’s crashing?

6

Rising clock edges were not fed at all to the clock.

7

Thanks Jens! The one you experienced I’m aware of and looking into :slight_smile:

I might actually have to do with the original crash: I need to recheck the Tides hardware source: the problem might stem from the Range button not being ignored when it should be (i.e. when in PLL mode).

8

Using Jens’ test patch above I can reproduce this 3 out of 4 times getting the same trace as per the log I posted back in July Tidal Modulator 1 crashes on Rack v2 · Issue #130 · VCVRack/AudibleInstruments · GitHub

9

Thanks Steve! Looking into it, will report back :slight_smile:

10

It’s definitely this section @ line 414.

11

I did more tests, after reading the issue you linked.

I can’t get it to crash when removing the cable, reconnecting and repeately clicking the frequency range button.

12

Makes sense, same problem as Mortuus’ ByteBeats… thanks :slight_smile:

13

I can’t get it to crash when just using the High mode, I need to connect a signal to the FM input and open the attenuverter.

14

I just pushed a potential fix and triggered a nightly, I’d be really grateful if you test it.

I can use FM now and the module chugs along happily.

The fix comes with a probable slight performance hit: dividing instead of shifting right; but I don’t think it’s that severe (better than crashing, always :stuck_out_tongue: )

The problem would probably also affect line 405 from the block Steve mentions, so that has been changed as well.

Lemme know how it goes :slight_smile:

If it goes well, I’ll probably go through the ByteBeats and do this for those that break, so, hopefully, 2 birds, 1 stone.

I’m going to bed: I’ve not been a happy camper today.

15

I’ve left you a quick note on this as an issue. A ByteBeats crash fix (maybe) · Issue #7 · Bloodbat/SanguineMutants · GitHub

16

Re-built from latest commits

1st test: crash

Thread 40 received signal SIGFPE, Arithmetic exception.
[Switching to Thread 7260.0x2838]
0x00007ffe706253c4 in tides::Generator::ProcessAudioRate (this=0xffe15b0, in=0xffe1681 '\006' <repeats 15 times>, "\017", out=0xffe1610, size=15)
    at eurorack/tides/generator.cc:398
398         int32_t slope_down = static_cast<int32_t>(0xffffffff / (~mid_point >> 16));
(gdb) bt
#0  0x00007ffe706253c4 in tides::Generator::ProcessAudioRate (this=0xffe15b0, in=0xffe1681 '\006' <repeats 15 times>, "\017", out=0xffe1610, size=15)
    at eurorack/tides/generator.cc:398
#1  0x00007ffe70671341 in tides::Generator::Process (this=this@entry=0xffe15b0, wavetableHack=false) at ./eurorack/tides/generator.h:161
#2  0x00007ffe706747c3 in Aestus::process (this=0xffe1460, args=...) at src/aestus.cpp:150

2nd test: crash (same section as before)

Thread 35 received signal SIGFPE, Arithmetic exception.
[Switching to Thread 10136.0x1fa0]
0x00007ffe711f53e7 in tides::Generator::ProcessAudioRate (this=0x116e6b50, in=0x116e6c21 '\006' <repeats 15 times>, "\017", out=0x116e6bb0, size=15)
    at eurorack/tides/generator.cc:410
410           uint32_t t = phase / (phase_increment / 65536);
(gdb) bt
#0  0x00007ffe711f53e7 in tides::Generator::ProcessAudioRate (this=0x116e6b50, in=0x116e6c21 '\006' <repeats 15 times>, "\017", out=0x116e6bb0, size=15)
    at eurorack/tides/generator.cc:410
#1  0x00007ffe71241341 in tides::Generator::Process (this=this@entry=0x116e6b50, wavetableHack=false) at ./eurorack/tides/generator.h:161
#2  0x00007ffe712447c3 in Aestus::process (this=0x116e6a00, args=...) at src/aestus.cpp:150

Squinky’s right - these denominators keep coming up zero

1 Like
18

He is right, indeed.

19

Yep, I saw, thanks :slight_smile:; but I’m going through this issue first: the ByteBeats no longer crash rack.

20

I don’t know what that comment of yours means, but:

a) clearly there is a divide by zero going on, regardless of rising clocks. b) as @Steve_Russell pointed out, there is clearly an uninitialized variable in one of the modules.

I know you didn’t write this old bad code, but these days I think everyone initializes their variable where they are declared so that this can’t happen. The idea being that if one later adds a variable it is possible to forget to initialize it in some Init function.

As others have pointed out, valgrind can easily find these code issues automatically.

private:
		uint16_t frequency_ = 0;
		uint16_t p0_ = 0;
		uint16_t p1_ = 0;
		uint16_t p2_ = 0;
		uint32_t t_ = 0;
		uint32_t phase_ = 0;
		uint8_t equation_index_ = 0;
21

Thanks, I’ll look into those after this one is not crashing.