painter.drawText() crashes under OSX Lion - not under Leopard
Qt 4.7.1, OS X 10.8
I’m drawing on a QPixmap. both drawText() and drawStaticText() crash under Lion, but do just fine under Leopard.
I don’t draw until the QPixmap has real size; then I get a painter, set up a font, and drawtext. Insta-boom — but only under Lion. I’ve verified the parameters to drawText() are reasonable: rect is within the QPixmap, text is good (four letters), alignment is composed of valid class enums. Opacity is 1, color is set to reasonable RGB value, font size is 16 (or default, smaller, still crashes).
The crash occurs deep in the apple OS;
I’ve googled, don’t see any relevant bugs. Any help?
I’ve been working on this for days now, same bug.
The crash occurs after several call layers in com.apple.ColorSync, after a call to…
- ConversionManager::ApplySequenceToBitmap(CMMConvNode*,CMMEncoDec&,CMMRunTimeInfo*,unsigned long,CMMProgressNotifier*)+12
…apparently there is something not set up, or set up poorly, for color transformation. Which is utterly bizarre… I can’t even find a word about color management in the Qt docs. And every other QWidget on this window draws properly, text or no.
I even took the original painter, created it without a constructor, called begin and end, created a new painter JUST to draw this stupid chunk of text… exact same error. Tried the 2nd painter both ways, too – with the QPixmap as the constructor parameter, or alone, then with begin and end. Crash. Crash. I moved the QWidget to a new location. Crash. I moved the widget to a new place in the UI order; Crash. I changed the text color. Crash. I changed the brush. Crash. I checked EVERY parameter to the drawText call (about 50 times) and they’re fine. A reasonable rect, a good font size, either the default font or a custom one, the QImage I’m drawing on has a defined size at the time of the call, the rect is within that region, the text is a simple 4-digit string, all the line drawing and etc is working fine on the same QWidget no matter what I do to it… yet, drawText(), and… Crash.
And also, the same calls to drawText() and drawStaticText work perfectly under OSX 10.6, (Snow Leopard), it’s only under 10.7, Lion, that it crashes at all. I’m ready to tear my hair out.
So…. in desperation, I’ve special cased out OS 10.7 (Lion) and when run under that OS, my app will simply not attempt to use painter.drawText() on that QWidget; this allows the app to run, albeit without frequency and other information drawn on the RF spectrum. Mind you, it draws text everywhere else with zero trouble. The QWidget in question covers the top half the window, underneath the menubar, and contains the waveform and waterfall (and the blue frequency string text, or it is supposed to) as you see in this image:
application screenshot [flickr.com]
This, of course, is a complete hack done out of zero options available and an utter lack of information, help and feedback. But I see no other alternative at this point. I would welcome even random guesses. Anything. From anyone. The silence is killing me nearly as much as the bug is.
Know why I couldn’t find a bug in my painter code? There wasn’t one. :/
What the problem was is that I had declared a large static array elsewhere – nothing even to do with this class – about 16 megabytes – and it would appear that this interacts with the amount of stack space the app gets.
Got my clue by cross-compiling for Windows, and it crashed the same way, but it crashed so early — before main — that I knew it had to be something with size / static allocation. The Mac apparently has enough room to do what I wanted, but just barely, and still affects the total stack space.
So, resolution, changed the static declaration to a calloc(etc,etc), and the problem went away immediately on both platforms — the windows version runs fine, and the Mac version now draws text and does everything else, too.
My supposition here is that Lion does more, goes deeper into the stack, than does Leopard and Snow Leopard, hence ran me out of whatever space had remained. One of the things I had noticed was that the call stack at the crash point was really deep, too, but I didn’t catch the hint at the time, since it looked like it was where it ought to be… didn’t occur to me that I’d made it dangerous to go there, though.
Something to keep in mind: large static allocations, no good. [knocks self on head]