Runtime Error : Location Common/runPicture.cpp:503

Seeing this in my OS X Cocoa builds:

Runtime Error : Location Common/runPicture.cpp:503 Condition: pic->image

And the crash log shows:

Application Specific Information:
Assertion failed: (pic->image, ""), function PictureHasAlphaChannel, file Common/runPicture.cpp, line 503.

With the crashed thread:

Thread 14 Crashed:
0   libsystem_kernel.dylib        	0x933f369a __pthread_kill + 10
1   libsystem_pthread.dylib       	0x9a0d5f19 pthread_kill + 101
2   libsystem_c.dylib             	0x97d75eee abort + 156
3   libsystem_c.dylib             	0x97d3e8c5 __assert_rtn + 399
4   XojoFramework.dylib           	0x01181690 0x117c000 + 22160
5   XojoFramework.dylib           	0x0128c287 0x117c000 + 1114759
6   XojoFramework.dylib           	0x01271d13 PictureHasAlphaChannel + 131
7   com.myapp   	0x00131505 Picture.HasAlphaChannel.Get%b%o<Picture>i4 + 50

I do have a bunch of MBS plugins in use, but this looks to me like a crash within the Xojo framework.


  • what causes it?
  • is there any way to trap it? This app has App.unhandledException handler but it seems like this error does not trigger it…?

my guess: A picture object where the underlaying picture is already released.

This could happen if a plugin function (or declare) releases the picture too often.

Yes, looks like I tried to load a ridiculously big picture using Picture.FromData() in a Picture subclass, and then when it failed I neglected to call Super.Constructor() on it - so I ended up with a half-initialized object that was causing problems. Solution: Don’t Do That :slight_smile:

This seems bad. Could you file a bug report?

Can you show some code?
I’m not aware that you can subclass picture and use it well.


The problem seems to be 100% due to failing to call Super.Constructor - it has nothing to do with large pictures at all (other than that being the situation which caused my buggy code to neglect to call Super.Constructor)

[quote=204194:@Christian Schmitz]Can you show some code?
I’m not aware that you can subclass picture and use it well.[/quote]

It does work, but it’s not very elegant : the problem is that there’s no easy way to make a picture subclass and then have your subclass picture data get into the actual superclass picture data - the solution (which is not ideal) is to actually copy the data from the subclass to the superclass when you create the picture. This has a disadvantage in that the memory requirements are 2x as high when preparing the picture.

In hindsight, if I were to redesign this class I might make it a “has a” pattern rather than an “is a” pattern – e.g. my custom picture class would not be a Picture subclass any longer, but would simply have a property which was a Picture object.