On 10/21/2013 02:36 PM, Clem, Brian T. wrote:

> Could my QT version be incorrect?  4 or 5?  But every time I try to select
 > a text tab (File) (Edit)(View)etc... it crashes and ruins my day... 
each time.

The way it's supposed to work with the svn version at the moment is that 
if you do a debug build, it crashes instantly any time there is a Qt 
warning.  This allows us to debug and fix many dozens of things that 
have been failing silently without having an obvious impact, and we have 
cleaned up a number of these problems.  As one example, there was a 
notation shortcut that never worked in all these years, and it took 
until now to discover this.

If you do a production build, without specifying any --with-debug 
options during ./configure, this isn't supposed to happen, and it should 
just crash due to the usual assortment of things that make Rosegarden crash.

I'm not sure which type of crash you're experiencing without more 
information than you've provided.

> QSpiAccessible::accessibleEvent not handled:  "6"  obj:  QMenu(0x2fd9fa0, 
> name = "Segments") "Segments"
> Aborted (core dumped)

It would be useful to get a stack trace from you, as it looks like that 
is probably one of these Qt crashes I'm talking about, and it looks like 
there's some potential you are doing something with your environment we 
don't know how to deal with properly.  We should fix that.  A debug 
trace would be most helpful.

I can't find any recent instructions on how to produce a stack trace, so 
let's just work through it here.

You'll be wanting to work from a command line in your terminal program 
of choice.

You'll need to use ulimit to allow for core dumps to be written.  I use:

   $ ulimit -c 1000000

You can replace "1000000" with "unlimited" too, but I guess I've always 
felt better having a limit, but a big one.

Now run Rosegarden (./rosegarden) and reproduce the crash.  Afterwards, 
you should find a file in your current directory called either "core" or 
"core.nnnn" where n are digits.

   $ gdb ./rosegarden core

After it grinds a few moments, you get to the gdb command line, and 
enter "bt" then post the results.  There will be a lot of statements like:

   #0 crashed on a dimwhizzle in segment/pointer/thingie.cpp:195 from
   #1 some/other/thingie from
   #2 some/different/thingie from

Paste that blob of #0...#1..#n statements, and we'll decipher it and fix 
the crash.  Hopefully the kind of crash you're having here will be a 
very quick, simple fix.  Any such crash testing you can do on 13.12 is 
greatly appreciated, and will make the release that much better.

> On a completely separate issue,  is there a way to change the splash RG
 > image?  Could I put a picture of a guitar or ... turkey... or soemthing
 > in place of the standard RG splash?  I mean, in theory, could it be done?

I just tried, and you can't override the splash at runtime.  You'd have 
to replace it in the source and recompile.  The --nosplash command line 
option works.

   $ rosegarden --nosplash

The latter is probably the best option under the circumstances.
-- 
D. Michael McIntyre

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135991&iu=/4140/ostg.clktrk
_______________________________________________
Rosegarden-user mailing list
[email protected] - use the link below to unsubscribe
https://lists.sourceforge.net/lists/listinfo/rosegarden-user

Reply via email to