rosegarden-user

Hi all,
All of a sudden, I started getting these messages when loading an .rg
file I use to sequence midi to my korg triton via a midisport 2X2:
KCrash: Application 'rosegarden' crashing...
This happens when I load the rg file made from a midi file, and select
device-->'external midi device 2' or 3. The only logs I get when I
click this is "rosegarden' crashing..." . This happens with my
keyboard on or off. Curiously, this was working last weekend just fine
et always until now. I haven't installed anything new or noticed any
hardware issues. This is happening on opensuse 10.1 . I was running rg
1.4, so I upgraded to 1.5.1 and the same exact issue happens.
Two side notes: I don't run jack, because I don't think I need it for
what I do, and my clock is at 250HZ just because its never been a
problem before (I hack the kernel for my day job, and haven't really
felt the urge to recompile and fix this when I'm in the middle of
playing piano).
I could build from source via svn or compile the kernel to be 1KHZ or
connect to jack if it'd help - I'd prefer to stick with rosegarden
since I know it somewhat and my needs are modest. Somehow since this
is a new issue I get the feeling it may be hardware issue, though rg
is crashing and not showing many clues. Any ideas?
Robert

On Sunday 02 December 2007, robert lazarski wrote:
> hardware issues. This is happening on opensuse 10.1 . I was running rg
> 1.4, so I upgraded to 1.5.1 and the same exact issue happens.
We'd be interested in getting you to run a debug build, and getting a stack=
=20
trace.
Unfortunately, I need to update the documentation explaining how to do this.
:(
> Two side notes: I don't run jack, because I don't think I need it for
> what I do
Shouldn't matter.
> I could build from source via svn or compile the kernel to be 1KHZ or
Most helpful thing would be to build SVN or the 1.6.0pre2 tarball=20
http://www.rosegardenmusic.com/pre/rosegarden-1.6.0-pre2.tar.bz2
and configure it by running ccmake . on it, then go in and flip on the=20
WANT_DEBUG option, and any other DEBUG looking stuff. (Not sitting in fron=
t=20
of me, sorry I'm being vague, I'm in a bit of a hurry to get back in the=20
other room so my wife stops screaming at me.)
Then you have to turn off the KDE crash handler and other things as explain=
ed=20
still accurately in this text snippet:
Go to a bash prompt (for example, run =E2=80=9CTerminal Program (Konsole)=
=E2=80=9D from the=20
KDE menu) and then issue these commands to allow for the creation of core=20
dumps, and to bypass the KDE bug handler:
for bash and similar shells:=20
ulimit -c unlimited
ulimit -H -c unlimited
export KDE_DEBUG=3D1=20
for tcsh and similar shells:=20
limit coredumpsize unlimited
setenv KDEDEBUG 1
Now start rosegarden from this same command line, and reproduce the crash. =
You=20
should now have a core file in your current directory. The core file is=20
either named "core" or "core.<number>".=20
Now run =E2=80=9Cgdb=E2=80=9D :=20
gdb rosegarden <core_file>
Now type =E2=80=9Cwhere=E2=80=9D at the gdb prompt. Let the trace run to co=
mpletion (or until=20
it becomes apparent that it's in an infinite loop) and copy the results, th=
en=20
paste them into your report.
=2D-=20
D. Michael McIntyre=20

On 03/12/2007, robert lazarski <robertlazarski@...> wrote:
> The build doesn't seem to be generating the executables for me.
cmake just generates the Makefile -- it's like "configure" in this
respect. You need to run make as well afterwards.
Chris

On Wednesday 05 December 2007 01:56, robert lazarski wrote:
> /home/iksrazal> rosegarden &
> [...]
> rosegarden: TrackButtons::slotTrackInstrumentSelection(0)
> Composition::getTrackById(0) - WARNING - track id not found, this is
> probably a BUG
> /home/iksrazal/gtk-gnutella-downloads/complete/rosegarden-1.6.0-pre2/rosega
>rden-1.6.0-pre2/src/base/Composition.cpp:1455 Available track ids are:
and
> /home/iksrazal> gdb rosegarden core
> [...]
> #0 Rosegarden::TrackButtons::slotTrackInstrumentSelection
> (this=0x8bcea28, trackId=0, item=32)
> at
> /home/iksrazal/gtk-gnutella-downloads/complete/rosegarden-1.6.0-pre2/rosega
>rden-1.6.0-pre2/src/gui/editors/segment/TrackButtons.cpp:957 957
> m_popupItem = position;
> (gdb) where
> #0 Rosegarden::TrackButtons::slotTrackInstrumentSelection
> (this=0x8bcea28, trackId=0, item=32)
> at
> /home/iksrazal/gtk-gnutella-downloads/complete/rosegarden-1.6.0-pre2/rosega
>rden-1.6.0-pre2/src/gui/editors/segment/TrackButtons.cpp:957 #1 0x08340138
> in Rosegarden::TrackButtons::qt_invoke (this=0x8bcea28, _id=54,
> _o=0xbfca02f0)
> at
> /home/iksrazal/gtk-gnutella-downloads/complete/rosegarden-1.6.0-pre2/rosega
>rden-1.6.0-pre2/RGbuild/TrackButtons.moc:232 #2 0xb7ad0e9d in
> QObject::activate_signal () from /usr/lib/libqt-mt.so.3 #3 0x08318ac1 in
> Rosegarden::TrackParameterBox::instrumentSelected (this=0x8b576e0, t0=0,
> t1=32)
I can't make head nor tail of this one.
If the last thing it prints before blowing up is "Available track ids are:",
then that means the Composition had no tracks in its track container. But
clearly it has had some tracks in its track container at some point
(otherwise nothing would have been displayed), and the document does contain
a track with ID zero, which is what is being requested.
So the Composition's track container has been emptied or become corrupted?
The absence of a track wouldn't be enough to explain why it would then crash
where it does. Assuming the line number in the trace is trustworthy, surely
the only reason to crash there would be if the TrackButtons pointer itself
was no longer valid. Unless I'm missing something obvious, this must be the
result of a problem that already happened, rather than the site of the
problem itself.
Chris

On Dec 4, 2007 8:56 PM, robert lazarski <robertlazarski@...> wrote:
>
> Here's my report running rosegarden-1.6.0-pre2 . I ran cmake with:
>
Sorry for replying to myself, but I decided to start from scratch with
1.6.0-pre2 and I repeated the error. Maybe I'm doing something so
wrong its never came up before ;-) . Anyways...
I start with this file:
http://braziloutsource.com/random/carnival_seq24_orig_play.mid
I route the 4 tracks thru my midi sport to my korg triton as this
screen shot shows:
http://braziloutsource.com/random/rg_crash1.png
All is well so far. Then I save the project to a rg file:
http://braziloutsource.com/random/rg_crash2.png
The error occurs when I close rg, import the rg file I just saved, and
choose a midi output system device.
hope that helps,
Robert

On Tuesday 04 December 2007, robert lazarski wrote:
> Sorry for replying to myself, but I decided to start from scratch with
> 1.6.0-pre2 and I repeated the error. Maybe I'm doing something so
> wrong its never came up before ;-) . Anyways...
This is a weird one. I can import, diddle, save, and reload your MIDI file,
or I can load, diddle, save, and reload your .rg file. No crashes here.
The difference is hard to fathom, but the most obvious difference we have is
with our MIDI setups. When I load this, it connects up somewhat differently,
latching onto what I actually have available. I wouldn't expect that to be
significant in of itself.
Let's see...
I edited your file externally (the raw XML) to change one of the names so I
could see what was originally connected to your MidiSport (it gets hooked up
elsewhere here.) I can assign a track to that without a crash. Tried a
couple others, same thing, same result.
I can't repeat the crash, and anyway, it looks like the crash is related to a
track ID problem, nothing to do with the studio at all, but track 0 is really
here, plain as the world.
I have no clue man. None. No insight, no intuition, no wild ass guess.
Maybe something in the trace will give Chris a hint it isn't giving me.
Do you experience the same phenomenon starting with any other random .mid
file?
--
D. Michael McIntyre