# Runtime Error : Location Common/runPicture.cpp:503 **URL:** \ **Category:** macOS\ **Created:** [August 2, 2015, 8:09pm UTC](https://forum.xojo.com/t/runtime-error-location-common-runpicture-cpp-503/25849 "2015-08-02T20:09:32Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Mike\_D](https://forum.xojo.com/user_avatar/forum.xojo.com/mike_d/32/266_2.png) [@Mike\_D](https://forum.xojo.com/u/Mike_D)\ **Post date:** [August 2, 2015, 8:09pm UTC](https://forum.xojo.com/t/runtime-error-location-common-runpicture-cpp-503/25849/1 "2015-08-02T20:09:32Z")
Seeing this in my OS X Cocoa builds: ```auto Runtime Error : Location Common/runPicture.cpp:503 Condition: pic->image ``` And the crash log shows: ```auto 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%oi4 + 50 [...] ``` I do have a bunch of MBS plugins in use, but this looks to me like a crash within the Xojo framework. Questions: - 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…? ---
**Author:** ![Christian\_Schmitz](https://forum.xojo.com/user_avatar/forum.xojo.com/christian_schmitz/32/158_2.png) [@Christian\_Schmitz](https://forum.xojo.com/u/Christian_Schmitz)\ **Post date:** [August 2, 2015, 8:27pm UTC](https://forum.xojo.com/t/runtime-error-location-common-runpicture-cpp-503/25849/2 "2015-08-02T20:27:48Z")
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. ---
**Author:** ![Mike\_D](https://forum.xojo.com/user_avatar/forum.xojo.com/mike_d/32/266_2.png) [@Mike\_D](https://forum.xojo.com/u/Mike_D)\ **Post date:** [August 2, 2015, 9:28pm UTC](https://forum.xojo.com/t/runtime-error-location-common-runpicture-cpp-503/25849/3 "2015-08-02T21:28:04Z")
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 🙂 ---
**Author:** ![Joe\_Ranieri](https://forum.xojo.com/letter_avatar_proxy/v4/letter/j/43a26b/32.png) [@Joe\_Ranieri](https://forum.xojo.com/u/Joe_Ranieri)\ **Post date:** [August 3, 2015, 12:45am UTC](https://forum.xojo.com/t/runtime-error-location-common-runpicture-cpp-503/25849/4 "2015-08-03T00:45:50Z")
> [@204147:@Michael Diehr](#): > > 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 🙂 This seems bad. Could you file a bug report? ---
**Author:** ![Christian\_Schmitz](https://forum.xojo.com/user_avatar/forum.xojo.com/christian_schmitz/32/158_2.png) [@Christian\_Schmitz](https://forum.xojo.com/u/Christian_Schmitz)\ **Post date:** [August 3, 2015, 8:30am UTC](https://forum.xojo.com/t/runtime-error-location-common-runpicture-cpp-503/25849/5 "2015-08-03T08:30:16Z")
> [@204147:@Michael Diehr](#): > > 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 🙂 Can you show some code? I’m not aware that you can subclass picture and use it well. ---
**Author:** ![Mike\_D](https://forum.xojo.com/user_avatar/forum.xojo.com/mike_d/32/266_2.png) [@Mike\_D](https://forum.xojo.com/u/Mike_D)\ **Post date:** [August 3, 2015, 2:35pm UTC](https://forum.xojo.com/t/runtime-error-location-common-runpicture-cpp-503/25849/6 "2015-08-03T14:35:16Z")
\<[https://xojo.com/issue/40290](https://xojo.com/issue/40290)\> 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) ---
**Author:** ![Mike\_D](https://forum.xojo.com/user_avatar/forum.xojo.com/mike_d/32/266_2.png) [@Mike\_D](https://forum.xojo.com/u/Mike_D)\ **Post date:** [August 3, 2015, 2:37pm UTC](https://forum.xojo.com/t/runtime-error-location-common-runpicture-cpp-503/25849/7 "2015-08-03T14:37:33Z")
[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. ---
**Author:** ![system](https://forum.xojo.com/uploads/default/original/1X/455b4dcc0e61630e9f81940004ddffa49c432a46.png) [@system](https://forum.xojo.com/u/system)\ **Post date:** [October 29, 2020, 5:52pm UTC](https://forum.xojo.com/t/runtime-error-location-common-runpicture-cpp-503/25849/8 "2020-10-29T17:52:27Z")