Segfault Surge XT

[tank-trax]

Debian 11 Bullseye

Operating System: Debian GNU/Linux
KDE Plasma Version: 5.20.5
KDE Frameworks Version: 5.78.0
Qt Version: 5.15.2
Kernel Version: 5.10.0-6-rt-amd64
OS Type: 64-bit
Processors: 4 × Intel® Core™ i5-3470 CPU @ 3.20GHz
Memory: 11.4 GiB of RAM
Graphics Processor: Mesa DRI Intel® HD Graphics 2500

./Surge\ XT 
SurgeXT : Version 1.0.xt-alpha.b94db5a1
id/ver='1' '1' '1'
That's a match. Lets not nuke
SynthProcessor: /home/studio/dev/tank-trax/surge-xt/src/surge_synth_juce/SurgeSynthStandaloneExtensions.cpp
Segmentation fault

[baconpaul]

Duo of #4479 - pull to head and you should be good

[tank-trax]

still segfaulting

./Surge\ XT 
SurgeXT : Version 1.0.main.3df2d75e
id/ver='1' '1' '1'
That's a match. Lets not nuke
SynthProcessor: /home/studio/dev/tank-trax/surge-xt/src/surge_synth_juce/SurgeSynthStandaloneExtensions.cpp
Segmentation fault

[baconpaul]

So 3df2 isn’t a hash I see in our repo
Can you pull to head of main and do a totally clean build? You still have some avx linked components somewhere

[baconpaul]

git fetch upstream
git checkout master
git reset upstream/master --hard
git push origin --force
git log | head -1
   > commit 7009024eb267e1176e1b83fde0921e9b69fb8785
cmake -Bignore/fresh -DCMAKE_BUILD_TYPE=Debug
cmake --build ignore/fresh --config Debug --target surge-xt-run-standalone --parallel 4

if that works you are good. If it doesn't type

gdb -- ignore/fresh/surge-xt_artefacts/Debug/Standalone/Surge\ XT

then once gdb starts type 'run' and tell me where the stack is

[tank-trax]

still segfaulting...

here is what I get

(gdb) run
Starting program: /home/studio/dev/extras/surge-xt/ignore/fresh/surge-xt_artefacts/Debug/Standalone/Surge XT 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
JUCE v6.0.7
SurgeXT : Version 1.0.main.7009024e
id/ver='1' '1' '1'
That's a match. Lets not nuke
[New Thread 0x7ffff6598700 (LWP 8120)]
SynthProcessor: /home/studio/dev/extras/surge-xt/src/surge_synth_juce/SurgeSynthStandaloneExtensions.cpp
[New Thread 0x7ffff54bc700 (LWP 8121)]
[New Thread 0x7ffff543b700 (LWP 8122)]

Thread 4 "Surge XT" received signal SIG32, Real-time event 32.
[Switching to Thread 0x7ffff543b700 (LWP 8122)]
__libc_read (nbytes=4, buf=0x7ffff543ad50, fd=9) at ../sysdeps/unix/sysv/linux/read.c:26
26      ../sysdeps/unix/sysv/linux/read.c: No such file or directory.

[baconpaul]

one you are there you can type 'where' and it will give you the whole stack.
that is a different crash than the one i just saw.

[tank-trax]

(gdb) where
#0  __libc_read (nbytes=4, buf=0x7ffff543ad50, fd=9) at ../sysdeps/unix/sysv/linux/read.c:26
#1  __libc_read (fd=9, buf=0x7ffff543ad50, nbytes=4) at ../sysdeps/unix/sysv/linux/read.c:24
#2  0x00007ffff54edfee in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#3  0x00007ffff54f175d in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#4  0x00007ffff54f15a2 in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#5  0x00007ffff54ecdbc in ?? () from /lib/x86_64-linux-gnu/libjack.so.0
#6  0x00007ffff7c67ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
#7  0x00007ffff79aedef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95

[baconpaul]

huh. is jack running properly on your system? if you blow away ~/.config/Surge XT.settings does it work?

[tank-trax]

jack is ok

this file appears to be missing

../sysdeps/unix/sysv/linux/read.c

[baconpaul]

yeah that's the std library
that error means surge xt is crashing doing a ::read (system level read) from jack. None of that is surge code.
Did blowing away the config help? I wonder if your jack is fine but you remembered a bad config?

[tank-trax]

maybe it's pipewire related

[baconpaul]

yeah
so we can figure that out by building the vst3 and seeing if it starts in reaper or carla or whatnot.

[tank-trax]

SurgeXT : Version 1.9.main.e679f249 loads

[tank-trax]

how do we uninstall and install assets locally for Surge XT using cmake? up until recently was uninstalling and installing using my own scripts... and the bash scripts that are no longer in the recent commits

it could be an assets not in their proper locations issue because all commits are segfaulting just after the GUI appears

[tank-trax]

I built commit 128ee2c locally on another computer
Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz

and it does not crash

so I nuked my user profile and that looks to have been the issue... upping from Buster to Bullseye looks to have required a rebuild of the local user profile under /home

that being said... running the debug using gbd still gives the same error... which in my opinion is problematic... also am not convinced squelching the SQL error is a fix... as it isn't a warning (but I could be wrong)

will close this because it's not exploding and the issue was local

[mkruselj]

@tank-trax i5-2500 does support AVX that's why it didn't crash.

[baconpaul]

128eee2c has the avx fix in and will run on an older system. I think the profile is what caused the crash here. It looks like xt was crashing deep in the jack code from the stack he shared.

[tank-trax]

I get the same error when running Debug and no crash.... I am thinking that GDB report is not reporting the crash but something else

the app is looking for ../sysdeps/unix/sysv/linux/read.c which does not exist

also this file does not exist either ../sysdeps/unix/sysv/linux/x86_64/clone.S

my guess is the AVX part needs source to build... the same way if I build an app with IPP support I need to DL the Primitives from Intel for Linux (but I could be wrong)

[baconpaul]

But: there is no AVX support right now. Nothing is using AVX at head and ave isn't on.

That looks like jack is failing an assertion harmlessly perhaps. If it's not a crash and just a stop in gdb that means there's something flagged but recoverable usually.

Those files are not from surge. They are from glibc. If you didn't build the std library from source you won't have them.