On 8/10/20 8:37 PM, liebre...@grossmann-venter.com wrote:
Rosegarden crashes deleting my recording in the process.
This is painful. Those ideas wont come around again. Lost forever.
I very definitely feel your pain here. It happened to me more times
than
I want to remember. So much creativity right out the window. One of the
most frustrating things we used to have was this stupid composition of
preset length. You're playing along, in the pocket, really coming up
with great ideas, and then WHAM, it just stops recording! I got that to
go away a long time ago, but the memories of all those notes still
linger.
Anyway, for the most part, Rosegarden is vastly more stable than it
used
to be. Thanks in great measure to Ted Felix coming along, and making
diligent and methodical efforts to improve this sort of thing. He was
generally very successful, but I guess we've experienced some kind of
regression.
All you can really do is start using a debug build from an environment
that allows core dumps.
The usual thing is to start running from development source, from a
debug environment. It's not absolutely necessary to run from
development
source, but it will help you in the long run. If the crash is
repeatable
(we hope it is!) and somebody (Ted Felix most likely) fixes it, then
you will want to be in a position to test the result.
Here are the instructions from the wiki:
How to get devel source:
https://www.rosegardenmusic.com/wiki/development_from_svn
How to get a stack trace for a crash
First, make sure you are running a version of rosegarden that was built
with debugging turned on.
-DCMAKE_BUILD_TYPE=Debug
Without debugging, there will be no symbols in the binary, and the
backtrace will be useless. You'll likely need to build rosegarden on
your own to get a debug version. Instructions can be found here: Using
the Eclipse IDE to work on Rosegarden
Open a terminal window, and check to ensure that applications will be
able to produce core dumps. The exact command and syntax may vary from
shell to shell, but for bash it is ulimit -a:
$ ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
...
The above example is quite typical for an end-user desktop system.
Having the “core file size†set to 0 prevents the creation of very
large
core dump files in unexpected places, and is generally a good thing.
However, this also prevents you from generating a stack trace. You need
to change the limit to something larger than 0, but many systems
prevent
you from setting this to unlimited, so we suggest
$ ulimit -c 1000000
Now start a debug version of rosegarden from the command line, and
reproduce the crash. You should now have a core file in your current
directory. The core file is either named core or core.<number>.
Run gdb:
$ gdb rosegarden <core_file>
Then once you get the gdb prompt, use the command 'bt' to get the stack
trace, and mail it to the authors or to the Rosegarden development
mailing list, or include it in a bug report.
Anyway, I hope this helps. I haven't been involved with development for
quite a number of years now, and I'm semi-retired. I still monitor
things, and still care. It's just my life went in a different
direction,
I guess. Especially in terms of working hours. When I was most
passionate about Rosegarden, and most active, I had the luxury of
making
a decent living working only 45 hours per week. Now it's closer to 80
with my commute.
Anyhoo brother, if I could turn back the hands of time and save your
ideas from getting obliterated, I would. I really hate it for you. So
much so that you inspired me to write the longest message I've posted
in
probably going on 10 years.
--
D. Michael McIntyre
