#1397 QT_FATAL_WARNINGS Crashes

None
closed
None
1
2013-09-21
2013-08-23
Ted Felix
No

Qt silently fails at runtime when signals and slots are messed up. Turns out there is a way to force it to crash at runtime in these situations (and possibly others as well):

$ export QT_FATAL_WARNINGS=1
$ ./rosegarden

You won't get very far. ISTM that we should fix all of these, then turn this on by default at the very least for a debug build. This will let us catch horrible problems immediately rather than letting a release go with a serious flaw.

It appears that what this does is stop the application whenever a warning is written to the debug output via qWarning(). See the following page for more:

http://qt-project.org/doc/qt-4.8/debug.html

Discussion

  • D. Michael McIntyre

    It might take months to fix all of these, but I like how you can control this without having to recompile.

    The vast majority of these signal/slot problems date all the way back to 10.02 and the massive rewrite it represented. Off the top of my head, there's some contentsMoving(int,int) thing I could never figure out a replacement for or fathom the original purpose of, and there are all kinds of things in the notation editor that used to control an informative and feature-rich status bar that has never been rewritten.

    At this point the current codebase is about five years old, with about three years of release history. I think it's safe to just go through and cull all this vestigial crap and dump it. Whatever it was, if we ever want it again, we're just as well off to invent it from scratch and do a clean implementation.

     
  • D. Michael McIntyre

    Thinking about that just a bit more, I realize I haven't seen the old KDE version of Rosegarden in years, and probably couldn't get it to build and run if my life depended on it. There's just no practical way to refer back to whatever has been lost, which makes it that much more sensible to go ahead and cull all this cruft.

    I culled a smart bit of cruft last time around too, come to think of it. I dumped a few thousand lines of somebody's hard work along the way, and I don't think anybody ever missed any of it.

     
  • D. Michael McIntyre

    You can also use:

    $ QT_FATAL_WARNINGS=1 ./rosegarden
    

    The very first one I see is from AudioRouteMenu, and I bet I know the cause of this one, albeit vaguely.

    So vaguely it turns out I'm not worth a damn at all at trying to explain what I think I know about it. It has something to do with the studio and/or the sequencer and/or threading just not all coming together correctly, and the record LEDs are not properly associated with instruments, even though they appear to be. Chris Cannam and I worked through several iterations of tinkering to improve this (him tinkering, me testing), and it's better than it was, but it's one of those elusive, mysterious, bitchy little things we just never got quite right.

    That should be a particularly nasty one right from the get go.

     
  • D. Michael McIntyre

    Or I could actually pull the three dozen changes I had pending and compile them before spending two hours talking out my ass about something you already fixed a year ago. Presumably.

     
  • Ted Felix

    Ted Felix - 2013-08-24

    I think we're going to find that it isn't too hard to work around these. Fixing them properly is another issue.

    Next I was going to try playing with QT_NO_DEBUG_OUTPUT which, when defined during the build, should turn off RG_DEBUG and leave only the warnings from Qt. This should let us see all the warnings and maybe sift through them and work on them in batches by type. Should make the work go faster.

    E.g. the current warning it stops on is related to actions:

    Already tracking action "Open in &Default Editor" under id 119

    I would need a few hours to re-figure out how all that works. So, I'd rather focus on signal/slot issues which can usually be "fixed" by commenting out code or checking pointers.

     
  • Ted Felix

    Ted Felix - 2013-08-27

    QT_NO_DEBUG_OUTPUT breaks the build. Use a non-debug build instead.

    The key to batching these is to run a release (non-debug) build and capture stderr. All the Qt warnings will be in there along with a few other things, but it's pretty easy to spot them.

    There are quite a number of these. Some of them are legitimate bugs, while others are just unused code. This will take some time to clean up. But it's pretty easy.

     
  • Ted Felix

    Ted Felix - 2013-08-28

    This should be closed as of r13381. Leaving it open for a bit in case anyone finds additional warnings.

     
  • Ted Felix

    Ted Felix - 2013-09-21
    • status: open --> closed
     

Log in to post a comment.