#1319 rosegarden doesn't start, waiting for something

[Anonymous]

I've compiled rosegarden in tinycorelinux. When I launch the program nothing happens, no error, no propt again, just waitng, so I did strace rosegarden and the last lines look like this:

pen("/usr/local/lib/libcrypto.so.0.9.8", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\0{\3\0004\0\0\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0555, st_size=1513038, ...}) = 0
mmap2(NULL, 1353720, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0xb575c000
mmap2(0xb588e000, 90112, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 3, 0x132) = 0xb588e000
mmap2(0xb58a4000, 10232, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb58a4000
mprotect(0xbf802000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC|PROT_GROWSDOWN) = 0
close(3) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb575b000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb575a000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5759000
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb5758000
set_thread_area({entry_number:-1 -> 6, base_addr:0xb5758710, limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}) = 0
mprotect(0xb5ea5000, 4096, PROT_READ) = 0
mprotect(0xb6027000, 8192, PROT_READ) = 0
mprotect(0xb6068000, 4096, PROT_READ) = 0
mprotect(0xb6122000, 16384, PROT_READ) = 0
mprotect(0xb6130000, 4096, PROT_READ) = 0
mprotect(0xb64e2000, 4096, PROT_READ) = 0
mprotect(0xb77fa000, 4096, PROT_READ) = 0
munmap(0xb77d7000, 23292) = 0
set_tid_address(0xb5758778) = 9530
set_robust_list(0xb5758780, 0xc) = 0
futex(0xbf802080, FUTEX_WAKE_PRIVATE, 1) = 0
futex(0xbf802080, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, bf802090) = -1 EAGAIN (Resource temporarily unavailable)
rt_sigaction(SIGRTMIN, {0xb64d2370, [], SA_SIGINFO}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0xb64d2800, [], SA_RESTART|SA_SIGINFO}, NULL, 8) = 0
rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=RLIM_INFINITY}) = 0
uname({sys="Linux", node="box", ...}) = 0
futex(0xb6127934, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0xb612d428, FUTEX_WAKE_PRIVATE, 2147483647) = 0
futex(0xb612d448, FUTEX_WAKE_PRIVATE, 2147483647) = 0
brk(0) = 0x945f000
brk(0x9480000) = 0x9480000
futex(0xb68e526c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
setsid() = 9530
time(NULL) = 1296472702
stat64("/usr/local/plugins", {st_mode=S_IFDIR|0755, st_size=220, ...}) = 0
stat64("/usr/local/plugins", {st_mode=S_IFDIR|0755, st_size=220, ...}) = 0
lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=160, ...}) = 0
lstat64("/usr/local", {st_mode=S_IFDIR|0755, st_size=260, ...}) = 0
lstat64("/usr/local/plugins", {st_mode=S_IFDIR|0755, st_size=220, ...}) = 0
futex(0x9474ad4, FUTEX_WAIT_PRIVATE, 1, NULL

[Anonymous]

the strace

[D. Michael McIntyre]

Hmmmm... There's not a lot I can think to do with this one.

When you ran "strace" did you use any options? The "-f" option is supposed to get it to trace through threads, although I'm not completely sure whether I'd expect that to work or not.

If that doesn't give a hint, there's not much for it but to step through Rosegarden in a debugger.

I did some brief research on Tiny Core Linux, and given the nature of that distribution, I wouldn't be at all surprised if there were obscure problems trying to get anything from the Linux audio spectrum to run on that distro. It could be lots of weird things that were sacrificed in the name of keeping the distribution as compact as possible. It could be almost anything.

If I saw a problem like this on one of the big, mainstream distros like Ubuntu or Fedora, I would be pretty freaked out right now, but I don't think we can guarantee ever resolving a problem on a distro so far off the beaten path for the Linux audio user.

[Ted Felix]

I've had rg hang at start when jack was acting up. The problem is in RosegardenSequencer::getInstance() which cannot lock the instance mutex because it is already locked by someone else. That someone else is stuck because creation of the RosegardenSequencer instance is stuck trying to start or talk to jack (jack_client_open() I think).

I have no idea if this is the same problem, but I recommend checking to make sure jack is running ok. Also try a debug build to get some debug output which might help. Running with gdb and getting a backtrace would be ideal.

[Dylan Simon]

I'm seeing what I believe is the same thing. The strace looks the same anyway. rosegarden-11.02 qt-4.7.1. Based on gdb and what this page implies https://bugs.launchpad.net/qbittorrent/+bug/592372 I tracked it down to the very first QSettings call trying to reaquire the settings mutex. The patch below to qt-4.7.1 fixes it. Clearly I am not suggesting that this is the right fix, but it does indicate the problem: qt > 4.6.3 doesn't like creating a QSettings before the app is initialized.

--- src/corelib/io/qsettings.cpp 2010/11/06 01:55:18 1.1
+++ src/corelib/io/qsettings.cpp 2011/02/24 02:15:51
@@ -117,7 +117,7 @@
Q_GLOBAL_STATIC(ConfFileCache, unusedCacheFunc)
Q_GLOBAL_STATIC(PathHash, pathHashFunc)
Q_GLOBAL_STATIC(CustomFormatVector, customFormatVectorFunc)
-Q_GLOBAL_STATIC(QMutex, globalMutex)
+Q_GLOBAL_STATIC_WITH_ARGS(QMutex, globalMutex, (QMutex::Recursive))
static QSettings::Format globalDefaultFormat = QSettings::NativeFormat;

#ifndef Q_OS_WIN

[D. Michael McIntyre]

Is anyone building and running successfully with Qt 4.7? I haven't upgraded my distro recently, and I have been unable to compile Rosegarden against a newer Qt from source. It compiles, but refuses to link, and I gave up trying to sort that out. As such, I've been doing everything recently with Qt 4.6.2.

We definitely create an instance of QSettings before the app is initialized, because we use QSettings to store certain parameters that have to be read before the app can be initialized. If we can no longer do that, we have a thorny problem.

Is anyone affected by this on Ubuntu, Fedora, OpenSUSE, Debian, or other similar distro? If this is limited to something like Tiny Core Linux, then I'm really just not that concerned, but if it's affecting the distros the majority of our users are using....

[D. Michael McIntyre]

After I upgraded to Kubuntu 12.04.1 I'm seeing this hang at startup every so often. Rosegarden freezes at various stages just before or just after putting up the splash screen, and the only thing for it is to kill the instance (eg. Ctrl+C) and try again. After a try or three, it eventually runs.

It might be worth putting some time into trying to figure this one out. I don't think this ever happens if jackd is already running, so it would seem it has something to do with starting jackd on demand at startup.

[D. Michael McIntyre]

In the course of tracking down another bug I did a long series of compile/test cycles, and I saw failure to start up to 60% of the time. It was annoying enough to push this from an irritation up to something intolerable.

I'm starting to develop a hypothesis that this all has something to do with PulseAudio. I think Rosegarden is starting JACK, and JACK is telling PulseAudio to relinquish the audio hardware, and Rosegarden tries to grab onto everything too soon and gets hung.

This is purely a hypothesis that has seen not even a shred of empirical testing, and may be completely invalid.

[D. Michael McIntyre]

Bug is so annoying I'd love to fix it, but I have no idea how. I've been poking around randomly for ages trying to figure out where it's getting hung, and can't figure it out.

Postponing.

[D. Michael McIntyre]

In the course of things, the hang at startup problem I was complaining about has largely disappeared again; probably since I updated to the newest Ubuntu LTS.

QSettings before the app is initialized, well, it's a much later Qt these days, and it would seem this is no longer the problem it was. I'm hopeful that's the case anyway.

[Ted Felix]

Nothing for two years? Time to close. If anyone is still seeing this, please provide additional details.