Getting an EXC_BAD_ACCESS / KERN_INVALID_ADDRESS when creating a view












1















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









share|improve this question

























  • 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











  • 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 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
















1















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









share|improve this question

























  • 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











  • 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 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














1












1








1








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









share|improve this question
















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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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








  • 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











  • 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



















  • 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











  • 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 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

















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












1 Answer
1






active

oldest

votes


















0














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.






share|improve this answer























    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
    });


    }
    });














    draft saved

    draft discarded


















    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









    0














    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.






    share|improve this answer




























      0














      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.






      share|improve this answer


























        0












        0








        0







        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.






        share|improve this answer













        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.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Feb 1 at 15:58









        MichaelGofronMichaelGofron

        6382921




        6382921
































            draft saved

            draft discarded




















































            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.




            draft saved


            draft discarded














            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





















































            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







            Popular posts from this blog

            A CLEAN and SIMPLE way to add appendices to Table of Contents and bookmarks

            Calculate evaluation metrics using cross_val_predict sklearn

            Insert data from modal to MySQL (multiple modal on website)