Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LMMS crashes when project loading is cancelled #3670

Closed
PhysSong opened this issue Jun 28, 2017 · 3 comments
Closed

LMMS crashes when project loading is cancelled #3670

PhysSong opened this issue Jun 28, 2017 · 3 comments
Labels

Comments

@PhysSong
Copy link
Member

PhysSong commented Jun 28, 2017

How to reproduce:

  • Open demo project Jousboxx-BuzzerBeater.mmpz
  • Press Esc key when progress is about 20%

Tested version: 1.2.0-rc3

The error message is: ASSERT: "c != NULL" in file /home/hjsong/lmms-stable-1.2/src/core/Song.cpp, line 1264

In the project, FX Ch11 uses peak controller from 'Sidechain' in B/B track, but this track wasn't load yet when I cancel loading.

Here's another example test.mmp.zip.

Song::restoreControllerStates() should handle this situation. Unfortunate
ly it doesn't.

If there's someone who has an idea, please write a comment.

Edit: When I removed Q_ASSERT(), there was no crash. However, in the context menu of knob which was connected to peak controller, LMMS says there is an controller connection(there can't be such connections because the controller isn't loaded).

@zonkmachine
Copy link
Member

Edit: When I removed Q_ASSERT(), there was no crash. However, in the context menu of knob which was connected to peak controller, LMMS says there is an controller connection(there can't be such connections because the controller isn't loaded).

I think this is how the user will experience it as the assert is probably only there if you build with the debug flag.

@PhysSong
Copy link
Member Author

PhysSong commented Jun 29, 2017

Then It is fine to fix the bug only?

Edit: If we clean out partially loaded project(like the suggestion in #3636), this issue will be automatically fixed.

lukas-w added a commit that referenced this issue Aug 29, 2017
Re-implement BufferManager using a single lock-free stack instead of two
fixed-size arrays. This has the following advantages:
 * Less code
 * Immediate re-use of released buffers, no blocking "refresh" required
 * Dynamic size, no crash when out of buffers (fixes #3670)
@PhysSong
Copy link
Member Author

Fixed in #3941, with #3636.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants