ok i figured it out with gdb, i get this after i try to run the reverb patch inside gdb:

(gdb) run
Starting program: /root/Bela/projects/reverb/reverb 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb693d450 (LWP 2621)]
__hv_noteout: 0xd1d4ac2
__hv_ctlout: 0xe5e2a040
__hv_pgmout: 0x8753e39e
__hv_touchout: 0x476d4387
__hv_polytouchout: 0xd5aca9d1
__hv_bendout: 0xe8458013
__hv_midiout: 0x6511de55
: 0

Thread 1 "reverb" received signal SIGBUS, Bus error.
0x00041e48 in sLine_init ()
(gdb)

sorry, i need a little assistance now :-)

list

will tell you where that happened.

You can also send me the patch and I will try to have a look. I am very afraid this could be something as horrible to track down as this one, and equally impossible to solve (as it was a bug in clang).

    giuliomoro

    OK, will do when i get home. is it easier for you with a simpler patch or can i send the original patch?

      if i try "list" in gdb i get:

      1	../sysdeps/arm/crti.S: No such file or directory.

      backtrace , then frame x to move the frame x of the ones listed. I will have a look at what you sent me later today.

      i don't really have an idea what this tells me...but i get the feeling this is not to promising 🙂

      root@bela:~/Bela/projects/reverb# gdb reverb
GNU gdb (Debian 7.12-6) 7.12.0.20161007-git
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from reverb...done.
(gdb) backtrace
No stack.
(gdb) run
Starting program: /root/Bela/projects/reverb/reverb 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
[New Thread 0xb693d450 (LWP 822)]
__hv_noteout: 0xd1d4ac2
__hv_ctlout: 0xe5e2a040
__hv_pgmout: 0x8753e39e
__hv_touchout: 0x476d4387
__hv_polytouchout: 0xd5aca9d1
__hv_bendout: 0xe8458013
__hv_midiout: 0x6511de55
: 0

Thread 1 "reverb" received signal SIGBUS, Bus error.
0x00041e48 in sLine_init ()
(gdb) list
1	../sysdeps/arm/crti.S: No such file or directory.
(gdb) backtrace
#0  0x00041e48 in sLine_init ()
#1  0x0004474c in Heavy_bela::Heavy_bela (this=0xa2e58, sampleRate=44100, 
    poolKb=10, inQueueKb=2, outQueueKb=0)
    at /root/Bela/projects/reverb/Heavy_bela.cpp:66
#2  0x000446c8 in hv_bela_new_with_options (sampleRate=44100, poolKb=10, 
    inQueueKb=2, outQueueKb=0) at /root/Bela/projects/reverb/Heavy_bela.cpp:50
#3  0x00067c14 in setup (context=0x8a9f0 <gContext>, userData=0x0)
    at /root/Bela/projects/reverb/render.cpp:399
#4  0x00026b3c in Bela_initAudio ()
#5  0x00019312 in main ()
Warning: the current language does not match this frame.
(gdb) frame 0
#0  0x00041e48 in sLine_init ()
(gdb) frame 1
#1  0x0004474c in Heavy_bela::Heavy_bela (this=0xa2e58, sampleRate=44100, 
    poolKb=10, inQueueKb=2, outQueueKb=0)
    at /root/Bela/projects/reverb/Heavy_bela.cpp:66
66	  numBytes += sLine_init(&sLine_Eco7brLC);
(gdb) frame 2
#2  0x000446c8 in hv_bela_new_with_options (sampleRate=44100, poolKb=10, 
    inQueueKb=2, outQueueKb=0) at /root/Bela/projects/reverb/Heavy_bela.cpp:50
50	    return new Heavy_bela(sampleRate, poolKb, inQueueKb, outQueueKb);
(gdb) frame 3
#3  0x00067c14 in setup (context=0x8a9f0 <gContext>, userData=0x0)
    at /root/Bela/projects/reverb/render.cpp:399
399		gHeavyContext = hv_bela_new_with_options(context->audioSampleRate, 10, 2, 0);
(gdb) frame 4
#4  0x00026b3c in Bela_initAudio ()
(gdb) frame 5
#5  0x00019312 in main ()
(gdb)

      well, so it's indeed an alignment issue as in the earlier issue. First off, I should have asked you to compile with CPPFLAGS="-O0 -g" CFLAGS="-O0 -g" (as it affects both C++ and C files), then you'd be able to see:

      Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
print o-[New Thread 0xb693c450 (LWP 28552)]
__hv_noteout: 0xd1d4ac2
__hv_ctlout: 0xe5e2a040
__hv_pgmout: 0x8753e39e
__hv_touchout: 0x476d4387
__hv_polytouchout: 0xd5aca9d1
__hv_bendout: 0xe8458013
__hv_midiout: 0x6511de55
: 0
>
Thread 1 "reverbtest" received signal SIGBUS, Bus error.
sLine_init (o=0xa6d48) at /root/Bela/projects/reverbtest/HvSignalLine.c:32
32	  o->x = vdupq_n_f32(0.0f);

      Then you'd inspect the address of o->x:

      (gdb) print &o->x
$3 = (float32x4_t *) 0xa6d58
(gdb)

      and you see that it is a float32x4_t which should be aligned to 16 bytes, but is actually aligned to 8 bytes.

      Turns out the problem is the whole Heavy_bela object should be aligned to 16 bytes, but it is not. I will have to dig deeper into this.

        giuliomoro I will have to dig deeper into this.

        i see, so would one option be to change the heavy generated c files before compiling? or is there no way around the bug in clang?

        thanks for looking into this and i guess i will stay with gcc for the moment.

          digging deeper, it seems it really is an issue with the clang.

          This simple test program

          #include <arm_neon.h>
#include <stdio.h>
#include <assert.h>

class MyClass {
public:
        float32x4_t c;
};

int main()
{
        printf("alignof(MyClass): %d\n", alignof(MyClass));
        printf("alignof(float32x4_t): %d\n", alignof(float32x4_t));
        for(int n = 0; n < 100; ++n)
        {
                auto ptr = new MyClass;
                printf("ptr: %p\n", ptr);
                printf("c: %p\n", &ptr->c);
                assert(((unsigned int)ptr & (alignof(MyClass) - 1)) == 0);
        }
        return 0;
}

          fails with clang. It work with gcc, but then gcc claims that alignof(float32x4_t) is 8 instead of 16, which I don't understand ...

          So, a current workaround would be to override operator new in the Heavy_bela class adding to the class Heavy_bela class declaration in Heavy_bela.hpp:

          #include <new>
....
class Heavy_bela {
...
  void* operator new(size_t sz) {
    auto ptr = aligned_alloc(16, sz);
    if(!ptr)
    {
     std::bad_alloc exception;
     throw exception;
    }
    return ptr;
  }
...
}

          however, the issue is fairly worrying and I need to find out if this is related to the version of clang, and if there is a more up-to-date one we can use instead.

          If this turns out to be needed, we could add the change to the hvcc template files.

            While I was looking into the performance align I noticed there is a Clang command line flag to set the default new() align, might be worth looking at that?

            What I found is an ancient discussion of gcc devs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=15795 . They mention that according to the c++ standard, the alignment of the pointer returned by operator new is undefined. As such, the behaviout observed with clang is the expected behaviour, however this makes all c++ code using the default operator new for classes with intrinsics unusable on Linux, where the underlying call to malloc() returns values aligned to 8 byte. On Mac (and I shall assume iOS), malloc() always returns a pointer aligned to 16 bytes, making this not an issue for many intrinsics.

            So yes, please, if you found a suitable flag for clang, tell us!

            looks like that option is not supported on the clang / gcc on the board. It was probably introduced more recently.

            Ah, what version of clang is in the board?

            It's 3.9 on the board. clang 6.0 seems to have it, and you can install it with apt-get from stretch backport (though I haven't tried: I just downloaded if from llvm.org).

            Haven't managed to make it produce the desired code yet, though.

            For whatever reason, on clang-3.9, alignof(float32x4_t) is 16 bytes, while on clang-6 (and on gcc-6.3), it is 8 bytes. Especially the clang-3.9 vs 6 is particularly weird, because their respective arm_neon.h includes are very similar ....

            I'm a bit confused!

            I though the original issue was that 3.9 wasn't aligning to 16?