Getting an EXC_BAD_ACCESS / KERN_INVALID_ADDRESS when creating a view
I'm creating a custom view that will be responsible for displaying some text.
BOOL DisplayBiggerString(Item *feedItem, CGFloat contentWidth) {
StyledString *const tryBiggerString = [feedItem buildBiggerString:[feedItem myStyle]];
CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
[testTextView setStyledString:tryBiggerString];
return testTextView.numberOfLines > 1;
}
It seems that it's crashing on the line:
CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
I'm not sure why it's causing a crashing for that view. The function inside just creates a new view like so:
if (self = [super initWithFrame:CGRectMake(0, 0, width, 1)])
I personally haven't been able to repro this as I can only respond to crash reports I've gotten. I checked the contentWidth and it's just getting the collectionView's width:
CGRectGetWidth(self.collectionView.bounds)
and this is done outside of a dispatch_async call which sizes the string when coming from cache:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
MakeTextCacheWarmup(newObjects, self.dataSource.feedSectionControllerComponents.itemConfiguration, width, width);
Is there some way to pass some width that would cause this to crash? I've tested all float values and they have seemed fine so far. Or is it a problem to create a view inside of the async block? I never add the view but merely use it to decide the number of lines of text
libobjc.A.dylib objc_msgSend
1CoreFoundation -[__NSSetM addObject:]
2UIKitCore UIViewDidSetNeedsDisplay
3UIKitCore -[UIView _createLayerWithFrame:]
4UIKitCore UIViewCommonInitWithFrame
5UIKitCore -[UIView initWithFrame:]
6MyApp __cmp_gen_92064(MYUserSession+MYMediaUploadManager.m:13)
7+MyApp DisplayBiggerString(MYConsumptionHelpers.m:12)
8+MyApp +[MYFeedItemTextCell buildStyledStringWithFeedItem:feedItemRow:pageCellState:configuration:contentWidth:textWidth:combinedContextOptions:userSession:](MYFeedItemTextCell.m:403)
9+MyApp __cmp_gen_8c7c(MYMainAppViewController.m:174)
10+MyApp MakeTextCacheWarmup(MakeTextCacheWarmup.m:47)
11+MyApp __81-[MYMainFeedViewController feedNetworkSource:didFinishLoadingObjects:withConfig:]_block_invoke.818
objective-c uiview
|
show 5 more comments
I'm creating a custom view that will be responsible for displaying some text.
BOOL DisplayBiggerString(Item *feedItem, CGFloat contentWidth) {
StyledString *const tryBiggerString = [feedItem buildBiggerString:[feedItem myStyle]];
CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
[testTextView setStyledString:tryBiggerString];
return testTextView.numberOfLines > 1;
}
It seems that it's crashing on the line:
CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
I'm not sure why it's causing a crashing for that view. The function inside just creates a new view like so:
if (self = [super initWithFrame:CGRectMake(0, 0, width, 1)])
I personally haven't been able to repro this as I can only respond to crash reports I've gotten. I checked the contentWidth and it's just getting the collectionView's width:
CGRectGetWidth(self.collectionView.bounds)
and this is done outside of a dispatch_async call which sizes the string when coming from cache:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
MakeTextCacheWarmup(newObjects, self.dataSource.feedSectionControllerComponents.itemConfiguration, width, width);
Is there some way to pass some width that would cause this to crash? I've tested all float values and they have seemed fine so far. Or is it a problem to create a view inside of the async block? I never add the view but merely use it to decide the number of lines of text
libobjc.A.dylib objc_msgSend
1CoreFoundation -[__NSSetM addObject:]
2UIKitCore UIViewDidSetNeedsDisplay
3UIKitCore -[UIView _createLayerWithFrame:]
4UIKitCore UIViewCommonInitWithFrame
5UIKitCore -[UIView initWithFrame:]
6MyApp __cmp_gen_92064(MYUserSession+MYMediaUploadManager.m:13)
7+MyApp DisplayBiggerString(MYConsumptionHelpers.m:12)
8+MyApp +[MYFeedItemTextCell buildStyledStringWithFeedItem:feedItemRow:pageCellState:configuration:contentWidth:textWidth:combinedContextOptions:userSession:](MYFeedItemTextCell.m:403)
9+MyApp __cmp_gen_8c7c(MYMainAppViewController.m:174)
10+MyApp MakeTextCacheWarmup(MakeTextCacheWarmup.m:47)
11+MyApp __81-[MYMainFeedViewController feedNetworkSource:didFinishLoadingObjects:withConfig:]_block_invoke.818
objective-c uiview
There isn't enough code here to really answer. Got a backtrace? How is DisplayBiggerString called? Why does[testTextView tryBiggerString]
even compile?
– bbum
Nov 26 '18 at 21:36
Yeah I have a backtrace and I've followed it to these points as I think they're the most relevant. My feeling is that the issue is a memory leak with creating the View inside of the calldispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
as it's not a main thread but I'm not 100% sure . MakeTextCacheWarmup eventually calls the functionDisplayBiggerString
but the callstack there is pretty long and involved so I isolated it to the where I suspect the issue to be in.
– MichaelGofron
Nov 26 '18 at 21:40
CoreTextView has a method that we calltryBiggerString
but based on callstack the error happens on view init i.e.:CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
which makes me suspect it's a memory leak issue as crashing on initializing a view seems pretty suspect imo. This is the backtrace after initializing the view:1 CoreFoundation -[__NSSetM addObject:] 2 UIKitCore UIViewDidSetNeedsDisplay 3 UIKitCore -[UIView _createLayerWithFrame:] 4 UIKitCore UIViewCommonInitWithFrame 5 UIKitCore -[UIView initWithFrame:]
– MichaelGofron
Nov 26 '18 at 21:42
1
BTW: ThetryBiggerString
variable inDisplayBiggerString()
is unused. Edit your question and add the full stack trace of the crash. Much easier to read than in a comment. In general, you should not be mucking with the UIKit on anything but the main thread ever (unless explicitly documented as safe).
– bbum
Nov 26 '18 at 23:15
Hey @bbum, I've added more details including the full stack trace. My suspicion as I mentioned earlier is that it's a problem with creating the view indispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
which is not the main thread.
– MichaelGofron
Nov 27 '18 at 15:49
|
show 5 more comments
I'm creating a custom view that will be responsible for displaying some text.
BOOL DisplayBiggerString(Item *feedItem, CGFloat contentWidth) {
StyledString *const tryBiggerString = [feedItem buildBiggerString:[feedItem myStyle]];
CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
[testTextView setStyledString:tryBiggerString];
return testTextView.numberOfLines > 1;
}
It seems that it's crashing on the line:
CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
I'm not sure why it's causing a crashing for that view. The function inside just creates a new view like so:
if (self = [super initWithFrame:CGRectMake(0, 0, width, 1)])
I personally haven't been able to repro this as I can only respond to crash reports I've gotten. I checked the contentWidth and it's just getting the collectionView's width:
CGRectGetWidth(self.collectionView.bounds)
and this is done outside of a dispatch_async call which sizes the string when coming from cache:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
MakeTextCacheWarmup(newObjects, self.dataSource.feedSectionControllerComponents.itemConfiguration, width, width);
Is there some way to pass some width that would cause this to crash? I've tested all float values and they have seemed fine so far. Or is it a problem to create a view inside of the async block? I never add the view but merely use it to decide the number of lines of text
libobjc.A.dylib objc_msgSend
1CoreFoundation -[__NSSetM addObject:]
2UIKitCore UIViewDidSetNeedsDisplay
3UIKitCore -[UIView _createLayerWithFrame:]
4UIKitCore UIViewCommonInitWithFrame
5UIKitCore -[UIView initWithFrame:]
6MyApp __cmp_gen_92064(MYUserSession+MYMediaUploadManager.m:13)
7+MyApp DisplayBiggerString(MYConsumptionHelpers.m:12)
8+MyApp +[MYFeedItemTextCell buildStyledStringWithFeedItem:feedItemRow:pageCellState:configuration:contentWidth:textWidth:combinedContextOptions:userSession:](MYFeedItemTextCell.m:403)
9+MyApp __cmp_gen_8c7c(MYMainAppViewController.m:174)
10+MyApp MakeTextCacheWarmup(MakeTextCacheWarmup.m:47)
11+MyApp __81-[MYMainFeedViewController feedNetworkSource:didFinishLoadingObjects:withConfig:]_block_invoke.818
objective-c uiview
I'm creating a custom view that will be responsible for displaying some text.
BOOL DisplayBiggerString(Item *feedItem, CGFloat contentWidth) {
StyledString *const tryBiggerString = [feedItem buildBiggerString:[feedItem myStyle]];
CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
[testTextView setStyledString:tryBiggerString];
return testTextView.numberOfLines > 1;
}
It seems that it's crashing on the line:
CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
I'm not sure why it's causing a crashing for that view. The function inside just creates a new view like so:
if (self = [super initWithFrame:CGRectMake(0, 0, width, 1)])
I personally haven't been able to repro this as I can only respond to crash reports I've gotten. I checked the contentWidth and it's just getting the collectionView's width:
CGRectGetWidth(self.collectionView.bounds)
and this is done outside of a dispatch_async call which sizes the string when coming from cache:
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
MakeTextCacheWarmup(newObjects, self.dataSource.feedSectionControllerComponents.itemConfiguration, width, width);
Is there some way to pass some width that would cause this to crash? I've tested all float values and they have seemed fine so far. Or is it a problem to create a view inside of the async block? I never add the view but merely use it to decide the number of lines of text
libobjc.A.dylib objc_msgSend
1CoreFoundation -[__NSSetM addObject:]
2UIKitCore UIViewDidSetNeedsDisplay
3UIKitCore -[UIView _createLayerWithFrame:]
4UIKitCore UIViewCommonInitWithFrame
5UIKitCore -[UIView initWithFrame:]
6MyApp __cmp_gen_92064(MYUserSession+MYMediaUploadManager.m:13)
7+MyApp DisplayBiggerString(MYConsumptionHelpers.m:12)
8+MyApp +[MYFeedItemTextCell buildStyledStringWithFeedItem:feedItemRow:pageCellState:configuration:contentWidth:textWidth:combinedContextOptions:userSession:](MYFeedItemTextCell.m:403)
9+MyApp __cmp_gen_8c7c(MYMainAppViewController.m:174)
10+MyApp MakeTextCacheWarmup(MakeTextCacheWarmup.m:47)
11+MyApp __81-[MYMainFeedViewController feedNetworkSource:didFinishLoadingObjects:withConfig:]_block_invoke.818
objective-c uiview
objective-c uiview
edited Nov 27 '18 at 15:47
MichaelGofron
asked Nov 26 '18 at 19:04
MichaelGofronMichaelGofron
6382921
6382921
There isn't enough code here to really answer. Got a backtrace? How is DisplayBiggerString called? Why does[testTextView tryBiggerString]
even compile?
– bbum
Nov 26 '18 at 21:36
Yeah I have a backtrace and I've followed it to these points as I think they're the most relevant. My feeling is that the issue is a memory leak with creating the View inside of the calldispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
as it's not a main thread but I'm not 100% sure . MakeTextCacheWarmup eventually calls the functionDisplayBiggerString
but the callstack there is pretty long and involved so I isolated it to the where I suspect the issue to be in.
– MichaelGofron
Nov 26 '18 at 21:40
CoreTextView has a method that we calltryBiggerString
but based on callstack the error happens on view init i.e.:CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
which makes me suspect it's a memory leak issue as crashing on initializing a view seems pretty suspect imo. This is the backtrace after initializing the view:1 CoreFoundation -[__NSSetM addObject:] 2 UIKitCore UIViewDidSetNeedsDisplay 3 UIKitCore -[UIView _createLayerWithFrame:] 4 UIKitCore UIViewCommonInitWithFrame 5 UIKitCore -[UIView initWithFrame:]
– MichaelGofron
Nov 26 '18 at 21:42
1
BTW: ThetryBiggerString
variable inDisplayBiggerString()
is unused. Edit your question and add the full stack trace of the crash. Much easier to read than in a comment. In general, you should not be mucking with the UIKit on anything but the main thread ever (unless explicitly documented as safe).
– bbum
Nov 26 '18 at 23:15
Hey @bbum, I've added more details including the full stack trace. My suspicion as I mentioned earlier is that it's a problem with creating the view indispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
which is not the main thread.
– MichaelGofron
Nov 27 '18 at 15:49
|
show 5 more comments
There isn't enough code here to really answer. Got a backtrace? How is DisplayBiggerString called? Why does[testTextView tryBiggerString]
even compile?
– bbum
Nov 26 '18 at 21:36
Yeah I have a backtrace and I've followed it to these points as I think they're the most relevant. My feeling is that the issue is a memory leak with creating the View inside of the calldispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
as it's not a main thread but I'm not 100% sure . MakeTextCacheWarmup eventually calls the functionDisplayBiggerString
but the callstack there is pretty long and involved so I isolated it to the where I suspect the issue to be in.
– MichaelGofron
Nov 26 '18 at 21:40
CoreTextView has a method that we calltryBiggerString
but based on callstack the error happens on view init i.e.:CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
which makes me suspect it's a memory leak issue as crashing on initializing a view seems pretty suspect imo. This is the backtrace after initializing the view:1 CoreFoundation -[__NSSetM addObject:] 2 UIKitCore UIViewDidSetNeedsDisplay 3 UIKitCore -[UIView _createLayerWithFrame:] 4 UIKitCore UIViewCommonInitWithFrame 5 UIKitCore -[UIView initWithFrame:]
– MichaelGofron
Nov 26 '18 at 21:42
1
BTW: ThetryBiggerString
variable inDisplayBiggerString()
is unused. Edit your question and add the full stack trace of the crash. Much easier to read than in a comment. In general, you should not be mucking with the UIKit on anything but the main thread ever (unless explicitly documented as safe).
– bbum
Nov 26 '18 at 23:15
Hey @bbum, I've added more details including the full stack trace. My suspicion as I mentioned earlier is that it's a problem with creating the view indispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
which is not the main thread.
– MichaelGofron
Nov 27 '18 at 15:49
There isn't enough code here to really answer. Got a backtrace? How is DisplayBiggerString called? Why does
[testTextView tryBiggerString]
even compile?– bbum
Nov 26 '18 at 21:36
There isn't enough code here to really answer. Got a backtrace? How is DisplayBiggerString called? Why does
[testTextView tryBiggerString]
even compile?– bbum
Nov 26 '18 at 21:36
Yeah I have a backtrace and I've followed it to these points as I think they're the most relevant. My feeling is that the issue is a memory leak with creating the View inside of the call
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
as it's not a main thread but I'm not 100% sure . MakeTextCacheWarmup eventually calls the function DisplayBiggerString
but the callstack there is pretty long and involved so I isolated it to the where I suspect the issue to be in.– MichaelGofron
Nov 26 '18 at 21:40
Yeah I have a backtrace and I've followed it to these points as I think they're the most relevant. My feeling is that the issue is a memory leak with creating the View inside of the call
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
as it's not a main thread but I'm not 100% sure . MakeTextCacheWarmup eventually calls the function DisplayBiggerString
but the callstack there is pretty long and involved so I isolated it to the where I suspect the issue to be in.– MichaelGofron
Nov 26 '18 at 21:40
CoreTextView has a method that we call
tryBiggerString
but based on callstack the error happens on view init i.e.: CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
which makes me suspect it's a memory leak issue as crashing on initializing a view seems pretty suspect imo. This is the backtrace after initializing the view: 1 CoreFoundation -[__NSSetM addObject:] 2 UIKitCore UIViewDidSetNeedsDisplay 3 UIKitCore -[UIView _createLayerWithFrame:] 4 UIKitCore UIViewCommonInitWithFrame 5 UIKitCore -[UIView initWithFrame:]
– MichaelGofron
Nov 26 '18 at 21:42
CoreTextView has a method that we call
tryBiggerString
but based on callstack the error happens on view init i.e.: CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
which makes me suspect it's a memory leak issue as crashing on initializing a view seems pretty suspect imo. This is the backtrace after initializing the view: 1 CoreFoundation -[__NSSetM addObject:] 2 UIKitCore UIViewDidSetNeedsDisplay 3 UIKitCore -[UIView _createLayerWithFrame:] 4 UIKitCore UIViewCommonInitWithFrame 5 UIKitCore -[UIView initWithFrame:]
– MichaelGofron
Nov 26 '18 at 21:42
1
1
BTW: The
tryBiggerString
variable in DisplayBiggerString()
is unused. Edit your question and add the full stack trace of the crash. Much easier to read than in a comment. In general, you should not be mucking with the UIKit on anything but the main thread ever (unless explicitly documented as safe).– bbum
Nov 26 '18 at 23:15
BTW: The
tryBiggerString
variable in DisplayBiggerString()
is unused. Edit your question and add the full stack trace of the crash. Much easier to read than in a comment. In general, you should not be mucking with the UIKit on anything but the main thread ever (unless explicitly documented as safe).– bbum
Nov 26 '18 at 23:15
Hey @bbum, I've added more details including the full stack trace. My suspicion as I mentioned earlier is that it's a problem with creating the view in
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
which is not the main thread.– MichaelGofron
Nov 27 '18 at 15:49
Hey @bbum, I've added more details including the full stack trace. My suspicion as I mentioned earlier is that it's a problem with creating the view in
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
which is not the main thread.– MichaelGofron
Nov 27 '18 at 15:49
|
show 5 more comments
1 Answer
1
active
oldest
votes
I figured out the issue with @bbum's help. The problem was with creating an instance of UIView
on a non-main thread. This results in a race condition which ultimately crashes the app.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53487479%2fgetting-an-exc-bad-access-kern-invalid-address-when-creating-a-view%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I figured out the issue with @bbum's help. The problem was with creating an instance of UIView
on a non-main thread. This results in a race condition which ultimately crashes the app.
add a comment |
I figured out the issue with @bbum's help. The problem was with creating an instance of UIView
on a non-main thread. This results in a race condition which ultimately crashes the app.
add a comment |
I figured out the issue with @bbum's help. The problem was with creating an instance of UIView
on a non-main thread. This results in a race condition which ultimately crashes the app.
I figured out the issue with @bbum's help. The problem was with creating an instance of UIView
on a non-main thread. This results in a race condition which ultimately crashes the app.
answered Feb 1 at 15:58
MichaelGofronMichaelGofron
6382921
6382921
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53487479%2fgetting-an-exc-bad-access-kern-invalid-address-when-creating-a-view%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
There isn't enough code here to really answer. Got a backtrace? How is DisplayBiggerString called? Why does
[testTextView tryBiggerString]
even compile?– bbum
Nov 26 '18 at 21:36
Yeah I have a backtrace and I've followed it to these points as I think they're the most relevant. My feeling is that the issue is a memory leak with creating the View inside of the call
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
as it's not a main thread but I'm not 100% sure . MakeTextCacheWarmup eventually calls the functionDisplayBiggerString
but the callstack there is pretty long and involved so I isolated it to the where I suspect the issue to be in.– MichaelGofron
Nov 26 '18 at 21:40
CoreTextView has a method that we call
tryBiggerString
but based on callstack the error happens on view init i.e.:CoreTextView *testTextView = [[CoreTextView alloc] initWithFrame:CGRectMake(0, 0, contentWidth, 0)];
which makes me suspect it's a memory leak issue as crashing on initializing a view seems pretty suspect imo. This is the backtrace after initializing the view:1 CoreFoundation -[__NSSetM addObject:] 2 UIKitCore UIViewDidSetNeedsDisplay 3 UIKitCore -[UIView _createLayerWithFrame:] 4 UIKitCore UIViewCommonInitWithFrame 5 UIKitCore -[UIView initWithFrame:]
– MichaelGofron
Nov 26 '18 at 21:42
1
BTW: The
tryBiggerString
variable inDisplayBiggerString()
is unused. Edit your question and add the full stack trace of the crash. Much easier to read than in a comment. In general, you should not be mucking with the UIKit on anything but the main thread ever (unless explicitly documented as safe).– bbum
Nov 26 '18 at 23:15
Hey @bbum, I've added more details including the full stack trace. My suspicion as I mentioned earlier is that it's a problem with creating the view in
dispatch_async(dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0), ^{
which is not the main thread.– MichaelGofron
Nov 27 '18 at 15:49