make: *** [run] Error 139

Fedde

There is a isolated part in my pd patch that causes the error below. But it doesn't occur when I run the isolated part as a separated patch. The patch contains 4 tabread4~ objects, 4 tables, a phasor and some multiplications and a part where the tables are initialised. Do you guys have any suggestions?

Running /root/Bela/projects/heavytest8/heavytest8 -p 128
Starting Heavy context with 23 input channels and 2 output channels
Channels in use:
Digital in : 13, Digital out: 0
Scope out: 0
MIDI device hw:1,0,0 is not ready: No such file or directory
Segmentation fault
make: *** [run] Error 139
Connection to 192.168.7.2 closed.

giuliomoro

Are you using a custom render file?
If yes, then probably the issue is in there.
If not, then this error is weird, can you send the patches, along with any useful debugging information to info bela.io?

Fedde

done

giuliomoro

I think the issue is this:

[until] is - even in Pd - a bad idea in many cases. Until recently it was not even implemented by heavy (for good reasons). Now it is, but it still requires the same care that it would require in Puredata, in this case with the added limitations of the embedded platform. What you are seeing here is probably a stack overflow which ultimately leads to a segmentation fault. I thought there used to be a way of increasing
Reflecting on your patch, you'll see that you are asking it to execute 1027 operations instantaneously. While this would make sense when initializing a table (as you are using it), doing it in Pd may have the effect you see.
The solution should be to change the patch so that you do not use the [until]. Instead, you could use a small delay (e.g.: [delay 0.01]) paired with a manual counter.
An alternative would be to populate the tables on the host computer with a manual bang instead of a [loadbang] (assuming you do not get a stack overflow there) and use the "save content" option of the array to save the values inside the patch.
Alternatively, you could populate the tables in C++.

giuliomoro

Actually no I am wrong, there is no feedback loop there, which would cause the stack overflow.
(yet you may be able to work around the issue in the way I described)
Still investigating.

Fedde

Maybe it due to the cause that I have another [until] instantiating in an other part of the patch. But there's no feedback loop there as well. I will check that out later today. Thank you for your help 👍

giuliomoro

No, actually a patch as simple as

[loadbang]
|
[100(
|
[until]

would segfault, but if instead of 100 you put 50, it would work.

giuliomoro

Ok, it may be a heavy-related issue. I would encourage you to use an alternative way of populating your table. Again, the [delay] trick above should work.