General live performance reliability

[unfa]

One of the bigger concerns I have right now with LMMS (and linux audio software in general) is the uptime of a single program.

Random crashes are very frequent, making me very unlikely to perform in front of an audience. Musicians can make most income from live gigs. I think focusing on this "live safe" aspect of our software can also bring us more serious users, and possibly more people and money to develop further.

I'd like to see a situation, where I can work on LMMS for 4 hours without a single crash no matter what I do with it. 5 days a week for a month. Not a single crash.

Do you think this is even possible? How can we get there?

How can we investigate crashes to find out what caused them and prevent that from happening again?

[tresf]

I'd like to see a situation, where I can work on LMMS for 4 hours without a single crash no matter what I do with it. 5 days a week for a month. Not a single crash.

I think we all want to be there...

Do you think this is even possible? How can we get there?

Yes, it is a matter of squashing bugs -- and in some cases -- rewriting core components. It's not an overnight process. The 2.0 branch was aimed to help making this possible by rewriting many core components, but it is currently stalled. The 1.x branch is getting there, but as you can see from our tracker, we have a lot to fix. 👍

[Umcaruje]

I really want to say that I think this is currently the weakest point in LMMS. To me, audio recording and all the other enhancements don't really matter if the software isn't stable like a concrete block. That said, I know that the path to this is hard, and we have a lot of people working on solving these bugs, and I'm really happy about that, and I think LMMS will reach this stability at some point.

How can we investigate crashes to find out what caused them and prevent that from happening again?

You can always run lmms inside gdb, and get a backtrace whenever you expirience a crash. Then you can make an issue with those segfaults and that would help a developers investigate the crash.

Now I'm not sure if there should be an issue for each of these random crashes, or just one huge issue with a lot of backtraces.

[unfa]

I'd like to take part in a crash-hunting campaign.

I just need to learn how I can help. Is there a tutorial for this?

[Wallacoloo]

Hey @unfa, here's a basic tutorial for debugging on the wiki: https://github.com/LMMS/lmms/wiki/Debugging-LMMS

Just get a debug build using the -DCMAKE_BUILD_TYPE=RelWithDebInfo up and running, and then whenever you use lmms, launch it via gdb ./lmms and type "run" at the prompt. If you ever get a crash, return to the gdb prompt and type "backtrace" & share the printout.

Running through gdb / compiling using the RelWithDebInfo might result in maybe a 10% performance penalty, but it shouldn't be too significant.

[midi-pascal]

@Wallacoloo What is the difference between -DCMAKE_BUILD_TYPE=RelWithDebInfo and -DCMAKE_BUILD_TYPE=DEBUG?
I use -DCMAKE_BUILD_TYPE=DEBUG now. Which one is the best?

[Wallacoloo]

@midi-pascal The difference between Debug and RelWithDebug is that the first passes -g -O0 to gcc, and the second passes -g -O2.

-O0 means optimization level 0, i.e. no optimizations. This is useful when you really get into in-depth debugging because you can inspect the value of every variable in the code, etc. When you use a higher optimization level, sometimes variables get completely optimized away, so when you try to print someVariable in the gdb console, you might get a message like <value optimized out>.

On the other hand, -O2 offers a significant performance gain over -O0, but you still retain enough debugging information to do stack traces and such.

So I use Debug for testing new features, and RelWithDebInfo if I'm going to be using lmms for an actual project but still want to be able to trace down bugs I encounter.

[midi-pascal]

@Wallacoloo Thanks for the explanation! So I will stick to the DEBUG option because the -O2 flag optimize out too much local variables to offer a full debugging context - to my taste -

[Wallacoloo]

Given that this issue is basically "fix all the bugs on our issue tracker", it seems a bit superfluous to me. I'm going to close this to keep the tracker clean. Comment or re-open if you object.

[acajaja]

Hi. I'm trying to get LMMS working reliably on Raspberry Pi 3 Jessie. Having all the same crashing probs. I will follow the debug instructions above. I am not a Linux dev, but I do [web] programming (PHP, Python, etc) so I know hot to debug and all that.

I'm excited to get this working on Pi and I hope we can figure it out. I think you should reopen this thread.

[tresf]

@acajaja live performance is something we all want to offer, but it isn't a single bug report, so it's impossible to track until it's started.

One component of that which suits some users is 99.9% stability. We're a long way from there. We have some plugins that either crash or silence output reliably and those bug reports will be our focus for time to come.

If we offer a live mode (like how Ableton does), it would probably require a new editor, one that encourages continual looping and the toggling on and off of segments. If and when that initiative starts, it will be tracked as such. I hope that clarifies why this bug report is closed.

That said, you are always welcome to comment in closed bug reports with useful information and if there's a particular closed bug report you have the ability to work on, let us know and we'd happily reopen it for you.