Random crashes while playing #2192
Comments
could you mention some of these 'parameters' specifically? |
|
@Umcaruje I have merged the fix for #2159 now I would be really helpful if you could describe "Change Parameters", :) I am concerned this is a bug from 1.1, and this is the first report, but that does not mean much. Could you possibly test master for this now #2159 is fixed, when you get time please |
|
@curlymorphic Change parameters: I twisted the Pitch knob on an AFP instance a lot, since I was tuning |
|
Looking at the back traces for stable 1.1 , they all point to an invalid index or null reference to bt1 https://github.com/LMMS/lmms/blob/stable-1.1/src/gui/FxMixerView.cpp#L493 It would be nice to find a way to reproduce this. being somewhat random, maybe keep an eye on disc access, or other heavy background tasks, |
eg automateable |
|
Done that now for 2 hours. There was no crash |
|
https://lmms.io/forum/viewtopic.php?p=11166#p11136 seems like another person experiences the same crashes. (crash2 and crash3) Since this now affects more people than me, gonna mark it as a bug. I experienced the same crashes on master, but they happened pretty rarely and quite randomly, when LMMS was minimised. |
|
Looks like I've got the same issue. LMMS hung right after I started it and pressed play in an empty session (no notes were played). I had to kill it, as it stopped redrawing the window or reacting to any user interaction. GDB output: |
|
Looks like a linux only thingie ? |
Since there is no way of debugging on windows yet, I don't think this can be ruled out as an linux-only bug. Back when I used windows, LMMS would also crash randomly on me. I can't say its this bug, but there is a big chance it is. |
|
Just got this crash while playing a project using sf2 player only and just listening (nothing else) in debug mode inside QT Creator. |
|
By playing the same project over and over again, I get some more information about the crash:
So I'm digging this one 😄 |
Could be a good idea to upload that project, then let it be a test-bed ? |
Of course it does. Even if the crash wasn't directly related to multiple simultaneous notes, it's more likely to happen where there are lots of notes. |
|
@softrabbit My phrasing was probably not adequate. I meant if I slow the tempo down the crash does not occur but if I speed it up - so the playing stresses the CPU more - it may occur. |
|
@musikBear I think I would not be allowed to upload the project since the original Midi file I imported in the project is copyrighted. FYI I use Lmms to re-orchestrate Midi files of old songs gathered on the net by adding tracks, instruments, humanize, beautify, ... |
|
I think I got this again in LMMS git master. This time LMMS froze, I thought it's gonna move on as it frequently stops reacting for a few seconds and then resumes fine, but not this time. |
|
@unfa The stack dump of the thread nb. 4 from my backtrace looks astonishingly similar to yours... |
|
Sup. I got some data loss today from this bug. For some reason I didn't find a recorver file after the crash happened. Here's the GDB output: http://pastebin.com/RwiTiuuj |
That's odd. What steps did you take after the crash? |
rm -rf /*.mmpz😈 |
Seriously: I closed the gdb terminal that was left open (I use a custom script that runs LMMS through gdb every time and keeps logs). LMMS was hung, it didn't shut down, so I had to xkill the window. Could somehow that have been interpreted by LMMS as a proper application shutdown and it removed the recover.mmpz file then? If so, that's nasty! |
It doesn't sound like any of the bugs I've been working on, but I think I saw it too once or twice. I don't know if LMMS can crash but still carry out the clean up sequence it does on closing and remove the recovery file.
Hm, a mod? |
|
@unfa Mixer::renderNextBuffer() stroked again in you last back trace. The more back traces I see and the more I see this method appearing. IMHO there is something wrong there - or around there - |
Hm, a mod? rm has a special check if you're trying to operate on the root directory. You need to add a special switch --no-preserve-root to make it allow you do such stuff. It wasn't present there from the beginning but I guess many people have fallen for "jokes" telling them to run rm -rf / and devs decided to protect the users from that. That's just my theory though. |
|
@unfa Probably. I was a moderator at the linuxmint forum for a couple of years and remember issuing warnings for occasional jokers having that line in their signature. |
|
I've just got another crash this time I can't see mixer playing a role here, looks like Qt Core... GDB output: http://pastebin.com/uUyn8xY1 |
|
Ok this happened again, I just played @Fastigium since you seem to be the current wizard on this kind of stuff, could you take a look at this please? |
|
@Umcaruje Hm, an interesting crash. For starters, it is Qt5-exclusive, as Qt4 does not assert However, that doesn't address the underlying problem. This assert fails because a different thread makes an extra reference to the internal data of QVector |
|
A-ha! The Edit: if this fixes the problem, then I fear all other uses of the |
|
@Fastigium nice catch. We have quite a few of these ... Edit: Just read your edit, so editing my edit to illustrate I've read your edit. 😄 |
|
@tresf Yeah, fun stuff 😁. I'd like to verify that this fixes things and maybe dig a little deeper in Qt's reasons for this change before recommending anything big, but it sure looks like this may require a major overhaul. @Umcaruje How often does this crash occur? Any chance to positively determine if it is fixed? In general, how soon are we supposed to fully support Qt5? Should fixing Qt5-specific problems be done before releasing 1.2.0? |
@Fastigium I've added it to the Qt5 list (#2611)
Ideally, yes. Practically speaking... that depends on this bug as well as whatever else crops up. My initial hope was to put a line in the sand at RC2. This would give us |
It happens at completely random, I'm afraid. It crashed once after idiling, once while playing, and once when I pressed stop. I'll check the branch and do a thorouugh test, when I find some time off. But I have to say that the random crashes are not only happening in qt5, I had this problem for over a year now (on different machines) You can check out the backtraces here: |
|
@Umcaruje Thanks for taking the time to test my PR! I'm responding here to keep the discussion in a single thread. The crash you're reporting now is of the same nature, but happens on a different variable, namely On a side note, those asserts only crash the program in DEBUG builds. In a release build, they are disabled (as long as QT_NO_DEBUG is defined, that is). However, a failing assert usually means Bad Stuff Going On. In this case, all that detaching means a performance hit in code that is executed every mixer round. Also, any modifications made to the Qt container inside a foreach loop are not preserved, which may lead to confusion and/or bugs. As for the other random crashes: hm, those backtraces are pretty old. I could look into them, but it would take some guessing to match the line numbers correctly. Also, are some of them from Dear me, what have we wrought by making LMMS multithreaded? Officially, if there is even a single write operation to a Qt container that may happen concurrently with read operations, every read and write access to that container should be synchronized. In practice, as far as I can see, this means that just about every Qt container access in the mixer code should obtain a lock. Which would make performance abominable. Alternatively, lock-free synchronization is possible by implementing and maintaining carefully thought-out design changes. For example, saving all container-altering operations in a thread-specific queue and performing them in a serialized fashion between mixing rounds would do. Hm. Perhaps I'll do some more reading on multithreaded programming. In any case, I'll see if I can get rid of foreach today. |
|
Not sure i should say anything here, but just fyi. |
|
|
@musikBear Thanks for the perspective, much appreciated 😊 @tresf Thanks for the reference! Though its title is promising, its actual purpose seems to be to reduce lock granularity. In other words, it replaces a small amount of widely-used locks with a larger amount of more locally-used locks. But it doesn't fix what I was talking about. Anyway, I'm prone to lose perspective sometimes. I'm a conscientious perfectionist, meaning that if I can't do something "right" or "perfect", it stresses me out a lot. A comment like @musikBear's helps me to recover my perspective. So if I start raving about these things again, just remind me that LMMS is already enabling lots of people to do great stuff, and that I'm just contributing to making it that little bit better 😌 That said, it still itches me that the mixer code is using Qt containers in a "wrong" way 😋. But perhaps a more nuanced view would do me some good: if we can make and keep the crash frequency low enough, doing it "wrong" might actually be worth the cost. By leaving out synchronization, we gain performance, and by refraining from complicated redesigns, we save time and make maintenance easier. Hm. Maybe "wrong" is right in this case. Well, food for thought. I'm not going to finish the foreach removal PR today, but maybe tomorrow. Thanks for all the teamwork, it feels good to be part of all this 👍 |
It also introduced more
Agreed. "Useful" is what we must deliver, "exactly perfect" is what we aim for. Hopefully we meet somewhere in the middle. |
|
tl;dr #2658 seems to fix bt2 😁 Small bit of progress on bt2: it seems to occur when QVector internal data Edit: ok, I've been able to reproduce bt2 4 times now on |
|
Closed by #2669 |
|
Ok, so another crash encountered today, different from the others (I can't reproduce yet, so not opening a new issue until I find a way). I was tweaking the pitch knob of a sample that was looped in the background, and got a crash: |
BufferManager::acquire() |
|
I get a similar crash if I set I also get this output. Edit: @Umcaruje I don't think this crash is related to the original post and I don't think the Buffer manager is the problem. Maybe you just ran out of buffers? Was it a heavy project? I tried to treat the audio file processor really bad but I couldn't make it crash. Maybe I just lack the right touch there... |
|
I agree that the crash is most likely caused by running out of buffers. OTOMH I see two possible causes: 1) LMMS was stressed real heavily and all the 512 buffers were actually in use, or 2) there is some code path that acquires buffers and does not release them. In case of 2, I'd very much like to find out which code path that is. @Umcaruje was LMMS stressed heavily when the crash occurred? If not, could you add a line like Oh, and @zonkmachine:
Nope, not in this case. The crash occurs before the value of i is set, so its value is meaningless at that point. The reason it exists is that there really is no such thing as declaring a variable in the middle of the contents of a function; the compiler just adds it to the current scope, so in gdb it shows up "before it's declared", if you get what I mean. |
Got it, thanks! |
Well, I had much more complex projects before, and this didn't occur. I know this has no connection with the original issue, but I don't want to open up new issues until I can surely reproduce the problem. And even though I ran out of buffers, I don't think LMMS should crash and let me loose all my work 😉 |
Yeah, the BufferManager is in a somewhat unfinished state. I reckon it hasn't been fixed because it hasn't been a problem so far. If you have the time to try what I wrote in my previous comment on this bug, it might shed some light on the problem. |
|
Hi, I see this is closed. I'm using the current version of LMMS on Raspberry Pi 3 Jessie. I'd be happy to upload my project and get involved with making this better, although I'm not a Linux dev. |
|
@acajaja a good starting point is to tell us the version you have running. Where did you get LMMS from? Was it compiled from source or did you find it with The most useful debug information is generally not available when downloading pre-compiled versions, such as through If you haven't compiled from source yet, we have a Discord channel available with people that can help. Once we find out more we can determine if your bug still exists and whether or not we should track it in a new bug report. |
|
Sounds good (pun intended with a ba-dum-dum)! I am using the pre-compiled binary from |
While using LMMS, I found that it crashes frequently while you play a pattern, BB track or the whole song and change parameters while doing that. It will also crash while just playing a project. I can't offer steps to reproduce, as this behavior is quite random. However, I made a debug build and collected backtraces from the crashes:
gist.github.com/Umcaruje/bf88cfb78948224120a9Crash under
bt2happened around 4 times, while the others happened only once. I will update that gist regularly with new backtraces.As far as I understand from reading these backtraces, this seems to be an issue with the Mixer code.
OS is Xubuntu 15.04 x64. The machine I use is not a very powerful one - Dual core 1.6 Ghz Intel processor and 2GB of ram. LMMS is compiled from source,
stable-1.1branch.masteris currently unusable for me because of #2159.Has a strong connection to #2153.
The text was updated successfully, but these errors were encountered: