A guy on the user list ran into a nasty crash on file open bug that turned out to be a Qt warning crash on a PNG library. Noisy warnings like that are pretty common with Qt, and usually their effects are limited, and tolerable. I would expect if this user could get past the automatic abort on any warning, he might find some of his icons had screwy transparency or something relatively superficial and unimportant.
When I asked for a stack trace, this user installed a -dbg package to get the symbols, and produced a stack trace promptly. I have a suspicion that the production release package is actually a debug build. That seems economical to me. Do one build, make it a debug build, then strip the symbols out of the release package and bundle them separately. I'm not sure how all of that actually works, since I'm no kind of package maintainer. The end result seems obvious enough: this end user distro package is crashing on an abort that should only fire in a debug build. So what should we do about this? Taking out the Qt crash on warning thing would be an easy quick fix for one specific class of problems, but I wouldn't be surprised if there are a lot of other unforeseen consequences of users running debug builds vs. production builds. Lots of extra code fires; profiling, extra debugging output. We've seen several different cases where there were bugs in this extra code, or bugs where this extra code was taken out of the loop. Seems to me the very first thing I want to know as a field surgeon doing triage is, "Is this a debug build?" Seems like having something inside debug ifdefs that makes a visible change could be a way to address that one. Append something to the about box, perhaps. That's a good idea either way, so we know what kind of build we're looking at when problems arise, but perhaps the bigger problem is a distro obviously shipping with a debug build in a production end user package in the first place. If they're really doing that, then we really just can't allow asserts in debug builds. Can we? I'm half the man I once was when it comes to any of this stuff. I remember how sharp I used to be, and it's sad. Then again, I have a new truck and make more money than ever, and oh yeah, an open marriage ;-) so being me is actually pretty damn cool right now; just not so great for Rosegarden. -- D. Michael McIntyre ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ Rosegarden-devel mailing list Rosegarden-devel@lists.sourceforge.net - use the link below to unsubscribe https://lists.sourceforge.net/lists/listinfo/rosegarden-devel
