Crash on recording mod-wheel - Segmentation Fault

Question

Crash on recording mod-wheel - Segmentation Fault

CarloCattano opened this issue 3 years ago · 12 comments

Steps :

Open a project with a few clips.
Start recording in one of them and move the mod-wheel. After a few seconds (maybe related to when comes to the end of the clip) , the application will crash with segmentation fault.

 ./seq192 -j -p 9000 -f ../template.midi
[1]    8629 segmentation fault  ./seq192 -j -p 9000 -f ../template.midi
❯ ./seq192 -j -p 9000 -f ../template.midi
[1]    9446 segmentation fault  ./seq192 -j -p 9000 -f ../template.midi
❯ ./seq192 -j -p 9000 -f ../template.midi
[1]    9561 segmentation fault  ./seq192 -j -p 9000 -f ../template.midi

I will investigate this further but still dont know how to debug in seq192 propperlly

Answer 1 · 2021-09-11T10:19:35.000Z

Here is the gdb information right before the crash:

[Thread 0x71b781f0 (LWP 10348) exited]
[Thread 0x6eea21f0 (LWP 10352) exited]
[Thread 0x6daff1f0 (LWP 10354) exited]
[New Thread 0x6daff1f0 (LWP 10386)]
[Thread 0x6daff1f0 (LWP 10386) exited]   ---- Till here no recording was made

Thread 2 "seq192" received signal SIGSEGV, Segmentation fault.   ---on crash 
[Switching to Thread 0x746351f0 (LWP 10341)]
0x76ed1550 in snd_midi_event_decode ()
   from /lib/arm-linux-gnueabihf/libasound.so.2
(gdb)

Answer 2 · 2021-09-11T10:26:59.000Z

Looks like CC's are not overriding previous CC info ? They just keep adding up till the crash

Answer 3 · 2021-09-11T13:30:47.000Z

I'll look into it, thanks.

Looks like CC's are not overriding previous CC info ?

Yes, same for notes. There's an overwrite record mode in seq32 that I could port in seq192.

Answer 4 · 2021-09-11T14:08:24.000Z

I'll look into it, thanks.

No pressure ! Sorry for being so up to it lately . I really like the stripped down version with osc , in adittion with open stage control is such a great tool honestly .

Yes, same for notes. There's an overwrite record mode in seq32 that I could port in seq192.

Right . Tbh , I never used the "override" mode on seqX for notes , since I can clear the clip now at will its not necessary In my particular case , and don't want to defeat the moto : "less features and more swag"

For CC's I would guess that other major apps do just a partial override , meaning that the new CC's and the old ones coexist and are replaced if the values differ somehow they interpolate the values or something ike that. In the case of seq192 a clean override (if CC value changed ) will possibly do just fine , to avoid the crash and be of great use

Answer 5 · 2021-09-12T09:22:53.000Z

Alright ! I didn't get to the segfault but I think it depends on the system's resources, anyway I have at least mitigated the issue by doing the following changes:

limit the number of recorded events* per quarter note to 48 so that they can be drawn properly in the UI
overwrite previous event* at current position when recording

Note that the overwrite is very simple and may leave old events in place depending on when the new events are received.

Answer 6 · 2021-09-12T13:02:08.000Z

limit the number of recorded events* per quarter note to 48 so that they can be drawn properly in the UI

overwrite previous event* at current position when recording

Hm , that did improve a bit but still getting to seg. fault.
I will double check my setup , try different routings and check the resources . I see a high consumption of cpu at times but must double check the other software I use for testing . All this is running on a pi3 b+ , then surely is not the best hardware to benchmark on . So many variables and little power .
Will keep investigating

Answer 7 · 2021-09-13T15:15:16.000Z

I tried a rather radical solution (0afa468), can you test it ?

Answer 8 · 2021-09-13T15:42:14.000Z

Of course , Right away!

Answer 9 · 2021-09-13T15:51:39.000Z

Now it is BULLETPROOF !
I even tried hard to make it crash , could not get to a crash even pushing it to un-realistic limits !

Also the overriding looks smoother . Its quite a bit of new lines and I dont fully understand it yet but will give it a read later . Thanks!
Let me know if you wonder about anything else

Answer 10 · 2021-09-13T18:19:51.000Z

Great !
The problem was that both the UI thread and the engine thread were accessing the sequence's content at the same time:

ui: iterates over all events in sequence and draw them
engine: updates event list when recording

The original code did handle the problem to some extent but it was causing glitches and crashes under stress conditions. Now instead the ui thread makes a copy of the event list before drawing the events and if the list changes, it doesn't affect the current frame's drawing process.

Answer 11 · 2021-09-15T07:18:13.000Z

Understood . I've come across this topic in previous tutorials where they always mention not to scramble threads with UI and audio etc .

Must say that now runs super well . I'm just preparing some more tests to run it completely headless once I get skilled with open stage control . I assume resources will reduce drastically , also when not using the desktop environment at all etc.

Thanks a lot for the effort!

Answer 12 · 2021-09-15T15:23:00.000Z

Here is my o-s-c ui for seq192 : https://github.com/jean-emmanuel/seq192-control. It uses some advanced o-s-c stuff and is not documented at all, but it may help :)