Crashes with juce::Image / CoreGraphics / iOS 12

MacOSX and iOS
1

Hi,

There definitely seems to be something wrong happening with juce::Image handling with CoreGraphics on iOS 12 (see this earlier thread).

Here are the clues I’ve gathered so far:

  • BubbleComponent uses a DropShadow by default (which can’t be disabled, BTW, unless touching the JUCE library code) which will make the crash happen. Easy to test: empty GUI project with a simple Slider on which you call setPopupDisplayEnabled(true, true, this). As soon as you drag the slider, the app crashes. Of course, the drop shadow compositing relies on juce::Image.
  • Other users seem to have problems when using juce::Image by itself: well, my app does as well, but fortunately, only the BubbleComponent's DropShadow caused it to crash.
  • When the problem happens, the debugger shows ERROR_CGDataProvider_BufferIsNotReadable.
  • Also, when debugging using breakpoints and step by step program execution, I eventually encountered a different error message: ERROR_CGDataProvider_BufferIsNotBigEnough.
  • There’s a pretty huge ongoing thread on Apple’s dev forum about it: https://forums.developer.apple.com/thread/94163
  • A collective suspicion is that this happens in a low-memory situation. But this feels weird in the context of the very simple one-Slider GUI project test.
  • When testing my app on iOS 12 on the simulator, it didn’t crash but the Slider's popup display was drawn incorrectly and showed a highly recognizable corrupted graphic buffer.

Some ideas for further investigation:

  • Try to figure out how exactly the crash is related to a juce::Image's size?
  • Run a test repeatedly creating new images, at different speeds/sizes/etc?
  • Any ideas or intuitions welcome :wink:

Best,

1 Like
2

In my case the crashes happened on iOS 11 , so I don’t think it is specific to version 12

3

I’m experiencing this pretty regularly in iOS 12. I mentioned one specific cause in the previous thread (drawing a copied image), but what’s more concerning is that it’s happening randomly at different points in the app. I can’t seem to use my app for more than a few minutes without it crashing.

I hope this gets fixed soon, as my number of angry iOS 12 customers is growing.

1 Like
4

I have a somehow similar problem, but on MacOS:
https://forum.juce.com/t/image-problem-after-xcode-update/29504

Could it be related to xCode 10 and not “only” iOS?
Best regards
John

5

I can confirm that this is happening when using the iOS 12 SDKs on a real iOS device inside Xcode 9.4.1 with JUCE 4.3.1 and JUCE 5.3.2.

What does this mean? Should we not use juce::Image’s in our code until this is fixed?

6

@jules @ed95 @fabian @t0m Perusing the links in this thread and the other linked items lead me to this comment in a github repo ERROR_CGDataProvider_BufferIsNotReadable crash · Issue #11690 · mapbox/mapbox-gl-native · GitHub

Hehe :slight_smile: I was using image manipulation with a CGContext to apply filters on images. With many images on one screen this lead to a memory issue (my best guess, because the non-expressive stack trace doesn’t tell exactly). Anyways, i switched to CIFilters and it works now :slight_smile:

Perhaps this is the solution for this bug?

edit:
after reading that long Apple Dev thread, this fix is suggested:

    if ([[UIDevice currentDevice].systemVersion floatValue] >= 11.0)
    {
        CGDataProviderRef provider = CGImageGetDataProvider(self.CGImage);
        NSMutableData *data = CGDataProviderGetInfo(provider);
        if(nil == data.bytes)
        {
            MFLogError(@"UIImage", @"convertToGrayscale, buffer not readable.");
            return self;
        }
    }

edit 2:
I can confirm that iOS 12.1 beta doesn’t have this problem. However, Component::createComponentSnapshot() doesn’t work anymore in juce 4.3.1 or JUCE 5.3.2.

If that function was never changed in the latest version of JUCE, then maybe whatever the bug was in iOS 12 has been fixed in 12.1 that caused the issue with juce::Image…

7

By a strange coincidence, today I’m getting this ERROR_CGDataProvider_BufferIsNotBigEnough error on my macbook pro running macos 10.13.6 (and xcode 9) – first time I get it on the mac, I think.

Update: hum I was wrong, it seems xcode has updated itself to version 10…

Update again: going back to xcode 9.4 makes that error disappear.

8

@JohnParbo @Hanley @sigmate have you guys made any progress on solving this crash for your apps?

9

Unfortunately no, except that I found that disabling the DropShadow effect on a Slider’s BubbleComponent allows my iOS app/plugin to run correctly. I pushed an update on the App Store so users can still use it but I wouldn’t call this “solving the issue”. I’m just lucky that this does the trick. And I have no choice but forking JUCE to disable the DropShadow :frowning:

1 Like
10

No, we had to go with a workaround. In our case the problem was caused by copying an image before drawing it. We just found another way to achieve what we needed without doing that. Sorry.

11

@fabian @ed95 @t0m @jules Pretty bump! Some feedback about this would be definitely appreciated, I guess. Could you at least confirm you can reproduce this? Thanks!

12

I think they’re all at CppCon, which goes through sunday. I saw tom’s and fabian’s names listed under 2018 speakers on CPPCon’s website.

1 Like
13

how would copying an image before drawing it cause any problems?
were you doing something like this?

void paint(Graphics& g)
{
   auto image = this->backgroundImage;
   g.drawImage(image, ...);
}
14 
Image bgCopy = boxImage[imageState].createCopy();
g.drawImageWithin (bgCopy...)
16

I’m curious why you were creating a copy in the first place though.

17

To change the image’s alpha according to varying opacity, without changing the original. The actual code was:

Image bgCopy = boxImage[imageState].createCopy();
bgCopy.multiplyAllAlphas(currentOpacity);
g.drawImageWithin (bgCopy...)
18

You realise that you can just call g.setAlpha (…) and then draw your image, right? Making a copy and modifying its pixels is very very slow.

(re: the original bug, we’ll have a look at that asap…)

19

:heart:
I wondered if you guys would have any downtime while at CppCon! :slight_smile:

20

I do now. Thanks.

21

Do you guys need a test project to replicate the bugs?