Alo Looper Memory Leak Where?

Using MOD devices Troubleshooting
#1

A number of my pedalboards uses the ALO Looper quite heavily. On some boards I have three instances of it. This has historically worked well, but recently I seem to be getting a number of crashes as the memory use goes up and up after every reopening of a board containing such loopers.

For example, using the board (and this being the current board in the system after power is attached to the mod dwarf)

I get:
image

Now just clicking on “Pedalboards Library” and clicking on the same board again to reload it I get:
image

Now just reloading it again, I get:
image

And again
image

And again
image
(Here it seems to have plateau’d).

In all the cases above, I did nothing, just reload the board in the browser.

Now choosing a virtually identical board (except no ALO Loopers)

image

Nothing changed (whatever seems to have been in memory is still in memory)

Now I unplug the mod dwarf, then plug it back in (with the same board with no ALO Loopers in it)

image

Now choosing it again from pedalboard library and reloading

image
Its pretty much the same.

Now again:
image

And again
image

And again
image

Therefore it doesnt seem there is anything in the other plugins causing this leak.

For reference, the other settings used on both boards are:
image

However, when I look in the code for the ALO Loooper

It seems to look ok from a memory point of view.

There is:

static const size_t LOOP_SIZE = 2880000;
...
//and in the insantiation function
self->recording = (float *)calloc(LOOP_SIZE * 2, sizeof(float));

	for (int i = 0; i < NUM_LOOPS; i++) {
		self->loops[i] = (float *)calloc(LOOP_SIZE * 2, sizeof(float));
		self->phrase_start[i] = 0;
		self->state[i] = STATE_RECORDING;
	}
type or paste code here

(which is obviously alot 2880000 * 14 - as well as a few other callocs, yet that all seems to be freed in the cleanup function)

static void
cleanup(LV2_Handle instance)
{
	log("Cleanup");

	Alo* self = (Alo*)instance;

	for (int i = 0; i < NUM_LOOPS; i++) {
		free(self->loops[i]);
	}
	free(self->low_beat);
	free(self->high_beat);
	free(self->recording);
	free(self);
}

So what could be causing this build up of memory.

I really hope I can solve this since the ALO looper is built into the way I use the mod dwarf - but recently I have had a crash on stage.

So if anyone can suggest any leads as to what might be going wrong that would be great. Also, could you see if you can reproduce the memory build up in the first board?

#2

The Alo Looper is a beta plugin, which means that it can be prone to issues.
With this disclosure in mind, since you didn’t have it before, have you, by any chance, updated the MOD OS before this started to happen?

#3

Thanks for getting back.

Regarding the time of update of the MOD OS - I think I just do the updates when they get notified. Here is the current state
image

What might complicate this is that I bought a second-hand mod to complement my existing unit, and have done the “Reboot and Update” process a few times between them. Possibly the first time I did that (around April time) I began to notice more frequent crashes (although this has gone together with me making ever more complicated pedalboards and so could be just coincidence)

This is the details of the second board, which seem identical (just dsp load higher because of different pedalboard)

image

Re-looking at the ALO looper code, the only place that looks a bit suspicious is in the reset() function

self->loop_samples = self->loop_beats * self->rate  * 60.0f / self->bpm;

	if (self->loop_samples > LOOP_SIZE || self->speed == 0) {
		self->loop_samples = LOOP_SIZE;
	}

LOOP_SIZE * 2 * sizeof(float) is the size ofthe initial calloc allocations (the 2 representing stereo I think).
This line suggests that its possible the number of samples being written could outnumber the initial allocation.

In the mod os, if any plugin was doing that, would one of the consequences be the failure to free memory between loading of different pedalboards?

The only other symptom of something going wrong, I’ve seen, is when constructing the second (no alo looper) board, which involved deleting the 3 alo loopers on the original one, there was a very long timelag (>10 seconds), between clicking the bin icons to delete them, and the deletion actually taking place.

Ive also had the "Bug: " toasts come up a few tijmes (in other occasions of adding plugins to boards with high memory use)