Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 23

Thread: Fix for "iOS 9.2 crashes" - the log pointing to the GLStateMachine

  1. #11
    Etablierter skobbler
    Join Date
    07.03.2016
    Posts
    42
    Hi, we go another disturbing crash:
    Code:
    #0
    Crashed: com.apple.main-thread
    EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x8000000012866f7b
     Raw
    0	
    std::__1::__tree, std::__1::allocator >, int>, std::__1::__map_value_compare, std::__1::allocator >, std::__1::__value_type, std::__1::allocator >, int>, std::__1::less, std::__1::allocator > >, true>, std::__1::allocator, std::__1::allocator >, int> > >::destroy(std::__1::__tree_node, std::__1::allocator >, int>, void*>*) + 4300369632
    1	
    std::__1::__tree, std::__1::allocator >, int>, std::__1::__map_value_compare, std::__1::allocator >, std::__1::__value_type, std::__1::allocator >, int>, std::__1::less, std::__1::allocator > >, true>, std::__1::allocator, std::__1::allocator >, int> > >::destroy(std::__1::__tree_node, std::__1::allocator >, int>, void*>*) + 4300369644
    2	
    std::__1::__tree, std::__1::allocator >, int>, std::__1::__map_value_compare, std::__1::allocator >, std::__1::__value_type, std::__1::allocator >, int>, std::__1::less, std::__1::allocator > >, true>, std::__1::allocator, std::__1::allocator >, int> > >::destroy(std::__1::__tree_node, std::__1::allocator >, int>, void*>*) + 4300369644
    3	
    std::__1::__tree, std::__1::allocator >, int>, std::__1::__map_value_compare, std::__1::allocator >, std::__1::__value_type, std::__1::allocator >, int>, std::__1::less, std::__1::allocator > >, true>, std::__1::allocator, std::__1::allocator >, int> > >::destroy(std::__1::__tree_node, std::__1::allocator >, int>, void*>*) + 4300369644
    4	
    std::__1::__tree, std::__1::allocator >, int>, std::__1::__map_value_compare, std::__1::allocator >, std::__1::__value_type, std::__1::allocator >, int>, std::__1::less, std::__1::allocator > >, true>, std::__1::allocator, std::__1::allocator >, int> > >::destroy(std::__1::__tree_node, std::__1::allocator >, int>, void*>*) + 4300369644
    5	
    opengl::GLProgram::~GLProgram() + 4300678564
    6	
    std::__1::__tree, std::__1::allocator >, int>, std::__1::__map_value_compare, std::__1::allocator >, std::__1::__value_type, std::__1::allocator >, int>, std::__1::less, std::__1::allocator > >, true>, std::__1::allocator, std::__1::allocator >, int> > >::destroy(std::__1::__tree_node, std::__1::allocator >, int>, void*>*) + 4300369644
    7	
    opengl::GLProgram::~GLProgram() + 4300678992
    8	
    opengl::detail::GLStateMachine::~GLStateMachine() + 4300631720
    9	
    opengl::detail::GLStateMachine::~GLStateMachine() + 4300626828
    10
    libsystem_c.dylib	
    __cxa_finalize_ranges + 428
    22
    UIKit	
    UIApplicationMain + 204
    23	
    main.m line 16
    main
    24	libdispatch.dylib	
    (Missing)

  2. #12
    Etablierter skobbler
    Join Date
    31.03.2016
    Posts
    14
    We've got a couple of them:

    Screen Shot 2016-06-20 at 11.07.45.jpg

    It makes a majority of crash reports we have logged on Fabric. Here's a batch of them taken from Xcode Organiser:

    Dropbox link

    There are some obscure things, like instant crashes right during app initialisation (related to MapSearch, what the hell, during init?) and a couple of MapSearch-, POIManager- and other C++-related stuff.
    Attached Images Attached Images

  3. #13
    Etablierter skobbler
    Join Date
    07.03.2016
    Posts
    42
    Same here. Hopefully a hot fix will be provided through pods, because it is not really nice

  4. #14
    Neuer skobbler
    Join Date
    30.03.2016
    Posts
    3
    I'd like to know if the pods have all the hot fixes too.

    Best,
    Holger

  5. #15
    Etablierter skobbler
    Join Date
    31.03.2016
    Posts
    14
    Guys, stop vitally rely on CocoaPods. You need to handle the case when needed.

    If you sacrifice 2 minutes of your time, you can take a look at a podspec file (do you guys even know how CocoaPods work, or do you just follow README manuals?), download the linked binary archive and find that CocoaPods-distributed binary is dated Thursday 1 October 2015. That means it's over half a year old, so most possibly, NO, they are not updated at all.

    When did programmers stop to research stuff, try to solve complications and begin to rely on product forums and wait until somebody does the job you should do in the first instance?

  6. #16
    Etablierter skobbler
    Join Date
    07.03.2016
    Posts
    42
    As it is a product distributed by pods we expect to put patches and fixes on pods. But I take your point.

  7. #17
    Dev platform evangelist dandronic's Avatar
    Join Date
    31.03.2014
    Posts
    177
    No - the pod does not have the hotfixes

  8. #18
    Etablierter skobbler
    Join Date
    07.03.2016
    Posts
    42
    Is it planned to be applied at some point in pods?

  9. #19
    Oberskobbler
    Join Date
    22.07.2014
    Posts
    399
    Once we'll release the 3.0 SDK (next month) we'll update also the pods that would come with this fix.

  10. #20
    Etablierter skobbler
    Join Date
    07.03.2016
    Posts
    42
    Thank you very much. This is great news!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •