CGAffineTransformInvert: singular matrix? Xojo or MBS?

We finally installed Xojo2013R2 and updated MBS to 13.2 today to test compile one of our apps. For some reason, this app now crashes during QA when our engineer continually resizes the app (while holding/dragging the corner of the app). It crashes around 10 seconds of continually resizing, which may point to some kind of a UI/threading issue in the app – but we have not investigated this yet.

Crashed Thread:  0  Dispatch queue:

Exception Codes: KERN_PROTECTION_FAILURE at 0x00000000bf7fff7c

VM Regions Near 0xbf7fff7c:
    Stack                  00000000b0833000-00000000b08b4000 [  516K] rw-/rwx SM=COW  
--> Stack                  00000000bc000000-00000000bf800000 [ 56.0M] ---/rwx SM=NUL  
    Stack                  00000000bf800000-00000000c0000000 [ 8192K] rw-/rwx SM=COW  

Thread 0 Crashed:: Dispatch queue:
0              	0x9a5be17f -[NSScrollerImpPair _updateOverlayScrollersStateWithReason:forcingVisibilityForHorizontalKnob:verticalKnob:] + 12
1              	0x9a5bf3b8 -[NSScrollerImpPair contentAreaScrolledInDirection:] + 160
2              	0x99dc249a -[NSClipView _immediateScrollToPoint:] + 589
3              	0x99dc20fc -[NSClipView scrollToPoint:] + 241

However, looking through the console log, there were a bunch of debug entries like (over 200+):

8/5/13 9:48:50.187 AM Test App.debug[783]: CGAffineTransformInvert: singular matrix.

Is this a Xojo thing or is this an MBS thing? Was it just some debug information that was not turned off in MBS when it came out of beta? It seems to be something with Core Graphics.

Please post the entire crashlog somewhere.

This bit is a bug with the framework with drawing round rectangles. It’s been fixed in a future release. I don’t think it’s related to your crash.

I’d like to see the whole crash report too… I never thought to try resizing a window for ten second or more!

Please feel to share any ideas you may have:

Sorry, I forgot to mention that we are testing this on the latest beta of Mavericks.

Indeed I see that, having a quick look it seems like its down to the TextArea, but I think will be able to better pinpoint the cause.

Is it also happening in your apps Sam? Crashing or just the debug info?

Please create a private Feedback case with a test project or a built application with steps to reproduce.


Once/If we isolate the cause(s), we will create a test project with the feedback. This is one of our major apps and it is quite large, so it may take some time to track down the cause(s) and create a specific sample case. The crash log shows the app as “Test App” because we are under a NDA.

Thanks for your time on this so far.

Ooops, as Sam had suggested, it is probably related to the TextArea. Specifically, it might be related to the scrollbars or control size being smaller than 0. Just for kicks, I created a brand new desktop app with only the TextArea control. I set the locking to all sides and resized the main window to make the TextArea smaller than 0. The app crashes with the debug message noted previously.

Feedback: <>

Our engineers have just confirmed that this bug also affects textfields, listbox, and password fields. There could be others, but we have stopped testing for now. It is important to note that the debug messages for some controls shows the following instead of the originally reported messages:

8/5/13 11:57:02.879 AM Test App.debug[1825]: Inconsistent set of values to create NSBitmapImageRep

Ouch. Why would you be setting controls smaller than or equal to 0?

We were not trying to set anything to smaller than 0 on purpose. With its properties locked, it just happens when we resize the main window. Either way, I hope this can be fixed as we normally don’t have textarea controls that are static in terms of size.

Can you set the window’s minimum size to something that would prevent the controls from having a dimension that is 0?

We could do that. In fact, our app has a min width and height of 1024x768. We make extensive use of container controls for the different views and each CC is uniquely laid out. To do find the least common denominator to work around this bug, I’m afraid the minimum width and height of the app will be almost as large as the screen itself (MacBook Pro 15 inch). Obviously we can rearrange the design/layout if it was our own app. But sometimes customers are very adamant about their layout designs. I won’t go into the rights/wrong or good/bad of app designs in terms of min app width/height, but I will say that we often create apps based on what our customers asks us to do.

Anyway, we also tried to come up with a subclass to prevent the affected controls to not go beyond 0. This prevents the app from crashing, but when we tested resizing the app quickly, the controls can sometime redraw much larger – going past the app’s right side or the app’s height.

Are you asking because this is a difficult bug to fix? I mean, it is pretty obvious that we can limit the size of a window/app as a workaround.

Doing something like this in the app’s resize/resized events prevents the crash, but it also creates a redraw issue as noted above.

  if textarea1.width <= 0 then
    textarea1.width = 0
  end if
  if textarea1.height <= 0 then
    textarea1.height = 0
  end if

I’m asking because it’s a strange thing to support and I’ve not heard of anyone else running into these issues. I don’t know if it’s a difficult bug to fix or not (yet).

I’m looking at it not from a support side as I can certainly redesign apps or keep this bug in mind for future apps/designs. I’m looking at this from a framework stability point of view since it can and will crash Cocoa apps. Sam has extensive skills in Cocoa and Xojo so it was obvious to him. Others, myself included, are not as skilled and would probably have taken a few hours or even days to track down bugs like this via a process of elimination, all the while thinking that it was our codes that was crashing our app.

My thinking is that if the controls are not meant to support negative values, Xojo should prevent controls from receiving negative values at the framework level. To be honest, I’m not even sure this is because of negative values as I don’t have access to the framework codes.

I guess we have become so reliant on RS doing the heavy lifting that we forget that things like this can happen. I can tell you that we have several apps that we never even considered having to think about control resizing issues beyond its smallest limitations in the past. I have to admit that we are probably using RS/Xojo incorrectly, so feel free to correct us.

I’m not trying to say that this bug is a show stopper (although it could be for some) and that it must be fixed immediately. I hope you understand that.

Anyway, thank you for looking into this and I hope to see a fix soon because we are not looking forward to changing the layouts of some of our apps.

Nona, There are probably hundreds of “bugs” like this waiting to be discovered, and will probably be hundreds as long as Xojo is a product. In any other framework you try, you’ll find a similar situation. Complicated software will always have a lot of bugs that don’t get exposed until someone exercises something just the right way to reveal the bugs. The best you can do is deal with it. Forums are great because if you can explain what’s going on, someone might have seen something similar and you can put your heads together to track down the problem and report it in a way that makes it fixable. Each Xojo release, you’ll see tens to a maybe a couple hundred little bugs fixed. It’s a process and that’s how it works.

I’m not seeing it in my apps, but it might be happening as I do get those annoying support e-mails “Your app is crap, it just crashes”… Like that’s going to help me figure out why it crashes for you and not others!