Skip to content
This repository was archived by the owner on Aug 31, 2021. It is now read-only.

[[ Bug 21396 ]] Fix crash on startup in iOS 12 beta - #6622

Merged
livecodepanos merged 1 commit into
livecode:release-9.0.1from
montegoulding:bugfix-21396
Aug 18, 2018
Merged

[[ Bug 21396 ]] Fix crash on startup in iOS 12 beta#6622
livecodepanos merged 1 commit into
livecode:release-9.0.1from
montegoulding:bugfix-21396

Conversation

@montegoulding

Copy link
Copy Markdown
Contributor

This patch fixes an issue where the view layer appears to be retaining the
CGDataProvider from an image when it is drawn via CGContextDrawImage.
As we were freeing the raster directly after the draw the CALayer could not
access it from the CGDataProvider when rendering causing a crash.

This patch therefore changes the behavior of MCGRasterCreateCGDataProvider
where previously when calling it with the copy parameter false it would be
left to the caller to free the buffer the data provider now takes ownership
of it and it is freed via the data provider free callback. As a consequence
of the change custom cursor creation on mac now copies the buffer for
simplicity.

@montegoulding montegoulding added this to the 9.0.1-rc-2 milestone Aug 3, 2018
Comment thread engine/src/mbliphonegfx.mm Outdated

glDeleteTextures(1, &t_texture);

free(p_bits);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a bit dodgy - surely the bits are owned by the MCGRaster which is passed in at a level above... Shouldn't the original caller be responsible for freeing? (assuming they aren't borrowed).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... I had just moved the free from UnlockPixels to here seeing as FlushBits in MCUIKitStackSurface takes ownership of them so I wanted FlushBits to take them in both cases.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you think of an alternative that doesn't involve copying the buffer in FlushBits for MCUIKitStackSurface given the CGDataProvider is expecting them to be available.

if (p_update)
FlushBits(p_area, p_raster . pixels, p_raster . stride);

free(p_raster . pixels);

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see that I'm leaking at the moment here in the case of ! p_update.. should now be:

if (p_update)
{
		FlushBits(p_area, p_raster . pixels, p_raster . stride);
}
else
{
		free(p_raster . pixels);
}

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@runrevmark perhaps FlushBits should set a boolean indicating if it has taken ownership of the bits? Then we can do:

bool t_taken = false;
if (p_update)
 		FlushBits(p_area, p_raster . pixels, p_raster . stride, t_taken);

if (!t_taken)
 		free(p_raster . pixels);

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@runrevmark I'm running with the above as it means I can only set x_taken if the raster is successfully converted to a CGImage. Will push up in a bit.

This patch fixes an issue where the view layer appears to be retaining the
`CGDataProvider` from an image when it is drawn via `CGContextDrawImage`.
As we were freeing the raster directly after the draw the `CALayer` could not
access it from the `CGDataProvider` when rendering causing a crash.

This patch therefore changes the behavior of `MCGRasterCreateCGDataProvider`
where previously when calling it with the copy parameter `false` it would be
left to the caller to free the buffer the data provider now takes ownership
of it and it is freed via the data provider free callback. As a consequence
of the change custom cursor creation on mac now copies the buffer for
simplicity.
@runrevmark

Copy link
Copy Markdown
Contributor

Okay so I think I have now stared at this too much! From what you said it fixes the issue and the code looks correct. So...

@runrevmark

Copy link
Copy Markdown
Contributor

@livecode-vulcan review ok 964d263

@livecode-vulcan

Copy link
Copy Markdown
Contributor

💙 review by @runrevmark ok 964d263

livecode-vulcan added a commit that referenced this pull request Aug 17, 2018
[[ Bug 21396 ]] Fix crash on startup in iOS 12 beta

This patch fixes an issue where the view layer appears to be retaining the
`CGDataProvider` from an image when it is drawn via `CGContextDrawImage`.
As we were freeing the raster directly after the draw the `CALayer` could not
access it from the `CGDataProvider` when rendering causing a crash.

This patch therefore changes the behavior of `MCGRasterCreateCGDataProvider`
where previously when calling it with the copy parameter `false` it would be
left to the caller to free the buffer the data provider now takes ownership
of it and it is freed via the data provider free callback. As a consequence
of the change custom cursor creation on mac now copies the buffer for
simplicity.
@livecode-vulcan

Copy link
Copy Markdown
Contributor

😎 test success 964d263

  • try-community-armv6-android-sdk26_ndk16r15: success
  • try-community-armv7-android-sdk26_ndk16r15: success
  • try-community-arm64-android-sdk26_ndk16r15: success
  • try-community-x86-android-sdk26_ndk16r15: success
  • try-community-x86_64-android-sdk26_ndk16r15: success
  • try-community-js-emscripten-sdk1.35: success
  • try-community-universal-ios-iphoneos11.4: success
  • try-community-universal-ios-iphonesimulator11.4: success
  • try-community-universal-mac-macosx10.9: success
  • try-community-x86-linux-debian8: success
  • try-community-x86_64-linux-debian8: success
  • try-community-x86-win32: success
  • try-community-x86_64-win32: success

@livecodepanos
livecodepanos merged commit 048f906 into livecode:release-9.0.1 Aug 18, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants