When starting rosegarden with a midi file passed on the command line, it's likely to die again soon with the following message: terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc As far as I understand things, this is because 1. I have a memlock limit of 500.000 KiB, as suggested by http://en.gentoo-wiki.com/wiki/JACK#Kernel_Configuration 2. jack_start_thread in the libjack client library will do a call to mlockall, thereby locking ALL pages which rosegarden has mapped into memory. 3. Rosegarden has a LOT of libs mapped, like qt4, kde stuff, and so on. So it reaches the limit rather easily. I guess most functions in those libs are never used at all, so having them memlocked is a waste of memory. The problem occurred only some of the time, not always. I guess when things worked, that's because the vsize had already exceeded 500MB by the time the jack thread was started. In that case, jack does fall back to a non-memlocked operation. I guess there are several options how to deal with this: 1. Issue an ewarn, instructing users that rosegarden might require a larger memlock limit than the Gentoo wiki suggests. 2. Adjust rosegarden to prevent all memlocking. Perhaps based on a USE flag. 3. Adjust rosegarden in such a way that only the relevant areas are actually memlocked. This might be a bit hard, but would be the best solution in the long run. Probably a task for upstream.
OK, I found out that the -m argument to jackd does solve the issue as well, although the -u argument does not. I had looked for such options in the rosegarden settings, but hadn't expected the jack daemon to control this aspect of client behaviour. If you add an elog (ewarn was a mistake) message, you might suggest the -m flag instead of or as an alternative to the memlock limit. It looks like -u should come close to solution 3, but otoh it looks as though it doesn't work as it should. Haven't looked at the code accompanying -u yet. If you consider all of this as a mere configuration issue that rosegarden users should know how to deal with, then close this as WONTFIX. In that case I'd write a forum article about it instead.