Crashes with juce::Image / CoreGraphics / iOS 12

That would be helpful, thanks!

Here’s mine: Slider + setPopupDisplayEnabled() (=> BubbleComponent => DropShadow => Image)

https://github.com/sigmate/JUCE_iOSDropShadowCrash.git

On real iOS 12 device: instant crash as soon as you touch the Slider. On Simulator: no crash but corrupted graphic buffer.

1 Like

have you tested with the ios 12.1 beta, by chance?

Not yet. Will do this week.

@ed95 care to check this crash out with iOS 12 and juce::Image/CoreGraphics?

It’s very difficult to work out what’s going on here. When you run with the address sanitizer enabled everything works flawlessly.

I have an empirical workaround, which prevents the crashes on my machine. In the CoreGraphicsImage class change

imageData.allocate ((size_t) lineStride * (size_t) jmax (1, height), clearImage);

to

imageData.allocate ((size_t) lineStride * (size_t) (height + 1), clearImage);

Please let me know if this improves things.

change that in juce_Image.cpp AND juce_mac_CoreGraphicsContext.mm ? That line is in both places…

You only need to change the one in juce_mac_CoreGraphicsContext.mm.

it didn’t solve it for me on a device running iOS 12. I need to find a device with iOS 12.1 to see if 12.1 still has the problem. and Component::createComponentSnapshot is broken still for me, using the latest development tip. it’s fine on iOS 11.4 though. it seems like Apple F’d something up…

I tried t0m’s fix on iOS 12.1, and it didn’t help. Our app is still crashing. I’ll try to make a small project to reproduce the problem tomorrow.

This is the minimal test case, in pure Obj-C (no JUCE):

- (void) drawRect: (CGRect) rect
{
    [super drawRect:rect];

    // 3 by 3 ARGB pixel data.
    size_t width = 3;
    size_t height = 3;
    size_t bitsPerComponent = 8;
    size_t pixelStride = 4;

    UInt8 data[] = {
        255, 255,   0,   0,     255,   0, 255,   0,     255,   0,   0, 255,
        255,   0, 255,   0,     255,   0,   0, 255,     255, 255,   0,   0,
        255,   0,   0, 255,     255, 255,   0,   0,     255,   0, 255,   0
    };

    CGDataProviderRef provider = CGDataProviderCreateWithData (0, &data[0], sizeof (data), 0);

    CGImageRef imageRef = CGImageCreate (width,
                                         height,
                                         bitsPerComponent,
                                         pixelStride * bitsPerComponent,
                                         pixelStride * width,
                                         CGColorSpaceCreateDeviceRGB(),
                                         kCGImageAlphaPremultipliedFirst | kCGImageByteOrder32Big,
                                         provider,
                                         0,
                                         true,
                                         kCGRenderingIntentDefault);
    CGDataProviderRelease (provider);

    CGRect imageRect = CGRectMake (0, 0, 100, 100);
    CGContextRef context = UIGraphicsGetCurrentContext();
    CGContextDrawImage (context, imageRect, imageRef);
    CGContextFlush (context);

    CGImageRelease (imageRef);
}

In iOS 12.0 there’s a subsequent draw operation that attempts to use the contents of data[], which in turn causes all the image weirdness happening at the moment. This feels like an Apple bug and I don’t think it’s something that can be fixed without some unpleasant delayed lifetime management.

1 Like

@t0m do you think that’s related to the testcase I showed here:

Yes, that’s another symptom of the same problem.

Thank you for this! Kinda scary, though… Is it worth filing a Radar? Or assume Apple already knows about it? Correct me if I’m wrong but even out of the scope of JUCE, this is about really basic functionality, that, if going wrong that way, is likely to impact a lot of projects, right?

Probably yes, but the more people file a bug report, the more priority it will get to be fixed. Worst thing that can happen is a generic feedback, like “This is a duplicate, but because of privacy reasons, we don’t update you on the progress” :wink: - but maybe they improved that now…

1 Like

Would definitely like to help (registered external Apple Developer are allowed to use Radar IIRC) but have not done this before. Would you suggest we all sing in unison (using the same report info like summary, description, use your minimal test code) or point out the same problem with our own words and cases?

I’ve already filed a bug report.

If you could reproduce the error in Swift that might make it a higher priority, but I’m second guessing the Apple internal politics.

I suspect there’s strength in diversity rather than multiple people submitting exactly the same report.

1 Like
3 Likes

you are the real MVP, bro!!!

Saved my day!!!