Crash in SChartGL::GLResources::glGen()


#1

I’m getting a rare crash from a small number of users reported through HockeyApp crash reporting service. I have never been able to reproduce the crash so I’m afraid I cannot provide more details. The crash happens with ShinobiCharts Premium 2.9.7. Below you’ll find the crash report I’m seeing:

Hardware Model: iPad5,4
Process: SystemStatus [6490]
Path: /var/containers/Bundle/Application/52416353-DF83-4B05-898D-D945E1CD32EE/SystemStatus.app/SystemStatus
Identifier: net.techet.sysstat
Version: 5.6.2 (5562)
Code Type: ARM-64
Parent Process: ??? [1]

Date/Time: 2017-11-14T05:00:04Z
Launch Time: 2017-11-14T05:00:02Z
OS Version: iPhone OS 11.1.1 (15B150)
Report Version: 104

Exception Type: SIGABRT
Exception Codes: #0 at 0x186cd9348
Crashed Thread: 0

Application Specific Information:
*** Terminating app due to uncaught exception ‘std::runtime_error’, reason: ‘Couldn’t initialise glObject. This is likely a problem with the GL context.’

Last Exception Backtrace:
0 SystemStatus 0x0000000100dd56bc SChartGL::GLResources::glGen(unsigned int*, void ()(int, unsigned int)) + 144
1 SystemStatus 0x0000000100e96538 SChartGL::VertexBuffer::VertexBuffer(std::__1::shared_ptr<SChartGL::ErrorHandlerHandle const>, SChartGL::VertexTraits const&) + 184
2 SystemStatus 0x0000000100e965b0 SChartGL::VertexBuffer::VertexBuffer(std::__1::shared_ptr<SChartGL::ErrorHandlerHandle const>, SChartGL::VertexTraits const&) + 32
3 SystemStatus 0x0000000100e3b730 SChartGL::BufferManager::setupBufferAndVBOs(SChartGL::GLResources&) + 360
4 SystemStatus 0x0000000100e3b574 SChartGL::BufferManager::BufferManager(SChartGL::GLResources&) + 200
5 SystemStatus 0x0000000100e3b9a0 SChartGL::BufferManager::BufferManager(SChartGL::GLResources&) + 32
6 SystemStatus 0x0000000100e85938 SChartGL::GLResources::GLResources(std::__1::shared_ptr<SChartGL::ErrorHandlerHandle const>) + 132
7 SystemStatus 0x0000000100e864d4 SChartGL::GLResources::GLResources(std::__1::shared_ptr<SChartGL::ErrorHandlerHandle const>) + 24
8 SystemStatus 0x0000000100e5336c SChartGL::Drawer::Drawer(bool, SChartGL::ErrorHandlerHandle const*) + 284
9 SystemStatus 0x0000000100e53648 SChartGL::Drawer::Drawer(bool, SChartGL::ErrorHandlerHandle const*) + 44
10 SystemStatus 0x0000000100dd6b10 -[SChartGLView drawer] + 188
11 SystemStatus 0x0000000100dd6c5c -[SChartGLView reset] + 100
12 SystemStatus 0x0000000100dd6d24 -[SChartGLView beginRenderWithReloadedData:] + 72
13 SystemStatus 0x0000000100ddd92c -[SChartCanvas drawChart:] + 1228
14 SystemStatus 0x0000000100dd9b0c -[SChartCanvasRenderView drawRect:] + 76
15 UIKit 0x000000019067a3c0 -[UIView(CALayerDelegate) drawLayer:inContext:] + 404
16 QuartzCore 0x000000018b1afa9c -[CALayer drawInContext:] + 292
17 QuartzCore 0x000000018b1af1bc -[CALayer _display] + 888
18 QuartzCore 0x000000018b122b50 CA::Context::commit_transaction(CA::Transaction*) + 516
19 QuartzCore 0x000000018b148eb4 CA::Transaction::commit() + 536
20 QuartzCore 0x000000018b149cf4 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 88
21 CoreFoundation 0x0000000187169848 CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 28
22 CoreFoundation 0x0000000187167200 __CFRunLoopDoObservers + 408
23 CoreFoundation 0x00000001871677bc __CFRunLoopRun + 1288
24 CoreFoundation 0x0000000187087fb8 CFRunLoopRunSpecific + 432
25 GraphicsServices 0x0000000188f1ff84 GSEventRunModal + 96
26 UIKit 0x000000019065c2f4 UIApplicationMain + 204
27 SystemStatus 0x0000000100c2f5e8 main (main.m:14)
28 libdyld.dylib 0x0000000186baa56c start + 0

Thread 0 Crashed:
0 libsystem_kernel.dylib 0x0000000186cd9348 __pthread_kill + 8
1 libsystem_pthread.dylib 0x0000000186ded344 pthread_kill$VARIANT$mp + 392
2 libsystem_c.dylib 0x0000000186c48fb8 abort + 136
3 SystemStatus 0x0000000100cf9108 uncaught_exception_handler + 28
4 SystemStatus 0x0000000100cea4f0 uncaught_cxx_exception_handler (BITCrashManager.m:188)
5 SystemStatus 0x0000000100cf1b3c BITCrashUncaughtCXXTerminateHandler() (BITCrashCXXExceptionHandler.mm:129)
6 libc++abi.dylib 0x00000001863ff54c std::__terminate(void (*)()) + 12
7 libc++abi.dylib 0x00000001863ff158 __cxa_rethrow + 140
8 libobjc.A.dylib 0x00000001864106e8 objc_exception_rethrow + 40
9 CoreFoundation 0x0000000187088024 CFRunLoopRunSpecific + 540
10 GraphicsServices 0x0000000188f1ff84 GSEventRunModal + 96
11 UIKit 0x000000019065c2f4 UIApplicationMain + 204
12 SystemStatus 0x0000000100c2f5e8 main (main.m:14)
13 libdyld.dylib 0x0000000186baa56c start + 0

Thread 1:
0 libsystem_kernel.dylib 0x0000000186cd9c1c __ulock_wait + 8
1 libdispatch.dylib 0x0000000186b47718 _dispatch_thread_event_wait_slow$VARIANT$mp + 32
2 libdispatch.dylib 0x0000000186b53038 _dispatch_sync_wait + 444
3 SystemStatus 0x0000000100c70bec -[FIRAIdentity identifierForVendor] + 232
4 SystemStatus 0x0000000100c7b474 -[FIRAMeasurement createRawEventMetadataWithUserAttributes:] + 940
5 SystemStatus 0x0000000100c78cb8 __43-[FIRAMeasurement writeEventOnWorkerQueue:]_block_invoke.1035 + 256
6 SystemStatus 0x0000000100c5b5a0 -[FIRASqliteStore performTransaction:] + 88
7 SystemStatus 0x0000000100c77cec -[FIRAMeasurement writeEventOnWorkerQueue:] + 1460
8 SystemStatus 0x0000000100c775e8 -[FIRAMeasurement handleEventOnWorkerQueue:] + 376
9 SystemStatus 0x0000000100c892e0 __52-[FIRAScheduler scheduleOnWorkerQueueBlockID:block:]_block_invoke + 40
10 libdispatch.dylib 0x0000000186b45088 _dispatch_call_block_and_release + 20
11 libdispatch.dylib 0x0000000186b45048 _dispatch_client_callout + 12
12 libdispatch.dylib 0x0000000186b4ee48 _dispatch_queue_serial_drain$VARIANT$mp + 524
13 libdispatch.dylib 0x0000000186b4f7d8 _dispatch_queue_invoke$VARIANT$mp + 336
14 libdispatch.dylib 0x0000000186b50200 _dispatch_root_queue_drain_deferred_wlh$VARIANT$mp + 396
15 libdispatch.dylib 0x0000000186b584a0 _dispatch_workloop_worker_thread$VARIANT$mp + 640
16 libsystem_pthread.dylib 0x0000000186deafd0 _pthread_wqthread + 928
17 libsystem_pthread.dylib 0x0000000186deac20 start_wqthread + 0

Thread 2:
0 libsystem_kernel.dylib 0x0000000186cd9dbc __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000186deac20 start_wqthread + 0

Thread 3:
0 libsystem_kernel.dylib 0x0000000186cd9dbc __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000186deac20 start_wqthread + 0

Thread 4:
0 libsystem_kernel.dylib 0x0000000186cb8bc4 mach_msg_trap + 8
1 CoreFoundation 0x0000000187169c74 __CFRunLoopServiceMachPort + 192
2 CoreFoundation 0x0000000187167840 __CFRunLoopRun + 1420
3 CoreFoundation 0x0000000187087fb8 CFRunLoopRunSpecific + 432
4 Foundation 0x0000000187ab16e4 -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 300
5 Foundation 0x0000000187ad0afc -[NSRunLoop(NSRunLoop) runUntilDate:] + 92
6 UIKit 0x00000001911bb2f4 -[UIEventFetcher threadMain] + 132
7 Foundation 0x0000000187bb2860 NSThread__start + 992
8 libsystem_pthread.dylib 0x0000000186dec31c _pthread_body + 304
9 libsystem_pthread.dylib 0x0000000186dec1e8 _pthread_start + 308
10 libsystem_pthread.dylib 0x0000000186deac28 thread_start + 0

Thread 5:
0 libsystem_kernel.dylib 0x0000000186cd9dbc __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000186deac20 start_wqthread + 0

Thread 6:
0 libsystem_kernel.dylib 0x0000000186cd9dbc __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000186deac20 start_wqthread + 0

Thread 7:
0 libsystem_kernel.dylib 0x0000000186cb8bc4 mach_msg_trap + 8
1 CoreFoundation 0x0000000187169c74 __CFRunLoopServiceMachPort + 192
2 CoreFoundation 0x0000000187167840 __CFRunLoopRun + 1420
3 CoreFoundation 0x0000000187087fb8 CFRunLoopRunSpecific + 432
4 CFNetwork 0x00000001877f2264 +[NSURLConnection(Loader) _resourceLoadLoop:] + 400
5 Foundation 0x0000000187bb2860 NSThread__start + 992
6 libsystem_pthread.dylib 0x0000000186dec31c _pthread_body + 304
7 libsystem_pthread.dylib 0x0000000186dec1e8 _pthread_start + 308
8 libsystem_pthread.dylib 0x0000000186deac28 thread_start + 0

Thread 8:
0 libsystem_kernel.dylib 0x0000000186cd9dbc __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000186deac20 start_wqthread + 0

Thread 9:
0 libsystem_kernel.dylib 0x0000000186cd9dbc __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000186deac20 start_wqthread + 0

Thread 10:
0 libsystem_kernel.dylib 0x0000000186cd9dbc __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000186deac20 start_wqthread + 0

Thread 11:
0 libsystem_kernel.dylib 0x0000000186cd9dbc __workq_kernreturn + 8
1 libsystem_pthread.dylib 0x0000000186deac20 start_wqthread + 0

Thread 0 crashed with ARM-64 Thread State:
pc: 0x0000000186cd9348 fp: 0x000000016f1df460 sp: 0x000000016f1df430 x0: 0x0000000000000000
x1: 0x0000000000000000 x2: 0x0000000000000000 x3: 0x000000016f1df3c8 x4: 0x0000000000000010
x5: 0x0000000000000020 x6: 0x0000000000000000 x7: 0x0000000000000000 x8: 0x0000000008000000
x9: 0x0000000004000000 x10: 0x0000000186df162c x11: 0x00000001b9d0dd24 x12: 0x00000001b9d0dd24
x13: 0x0000000000000018 x14: 0x0000000000000001 x15: 0x0000000000000881 x16: 0x0000000000000148
x17: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x0000000000000006 x20: 0x00000001b79deb80
x21: 0x434c4e47432b2b00 x22: 0x0000000000000303 x23: 0x00000001b79dec60 x24: 0x00000001c8007e90
x25: 0x0000000000000000 x26: 0x0000000000000001 x27: 0x0000000000000000 x28: 0x000000016f1dfb30
lr: 0x0000000186ded344 cpsr: 0x0000000000000000

Link Register Analysis:
Symbol: pthread_kill$VARIANT$mp + 392
Description: We have determined that the link register (lr) is very likely to contain the return address of frame #0’s calling function, and have inserted it into the crashing thread’s backtrace as frame #1 to aid in analysis. This determination was made by applying a heuristic to determine whether the crashing function was likely to have created a new stack frame at the time of the crash.
Type: 1


#2

Hi techet,

I’m sorry that some of your users are experiencing a crash.

Are all the crash reports on iOS11, or are any previous versions affected?

Can you let me know whether your app has Address Sanitizer turned on?

Kind regards,

Alison


#3

This happens on iOS 10 too (I support iOS 10 and 11 only now so I don’t know about other iOS versions). Address sanitizer isn’t turned on in the release builds where the crash happens.


#4

Hi techet,

Thanks for the further information. We haven’t seen a crash like this before in the circumstances you describe, so we’d really appreciate it if you could give us more details of your app, and what it is (or is likely to be) doing at the point of the crash. Please could you send the details to us at info@shinobicontrols.com?

Thanks,

Alison


#5

First, this crash is really rare (something like 1 in 10000 runs of the app) so not really urgent and probably not worth of much of your time.

But maybe I have a theory - in the past I was experiencing this problem

where OpenGL wasn’t properly terminated when entering background. Because of this I added an UIApplicationDidEnterBackgroundNotification observer which calls glFinish() which at least partially mitigated the problem. In the last few years though it seems it has been fixed on the Shinobi side - at least I haven’t seen these crashes any more. Am I right to assume this is the case and that I can remove glFinish() calls from the app?

Now what I suspect is that (somehow - it’s not really clear to me how it could happen) Shinobi redraw is triggered after glFinish() call inside my app which might cause the error. So removing glFinish() if it’s safe to do might fix the issue.


#6

Hi techet,

We have made some changes over the years to deal better with background threads. Version 2.8.0 introduced a flushPendingGLOperations method which can be called when the app is backgrounded: this should be safer than calling glFinish directly. Additionally, version 2.9.8 fixed some issues with background threads in the framework, following the introduction of Xcode 9’s Main Thread Checker.

Following Apple’s advice on Implementing a Multitasking-Aware OpenGL ES App, here’s how we suggest you deal with background threads when using shinobicharts:

  1. In your app delegate’s applicationWillResignActive method, your app should cancel any timers, call the chart’s flushPendingGLOperations method and call setIsEnteringBackground(true) on the chart.
  2. If there is any code running on a background thread which updates the chart data, your app should avoid attempting to redraw the chart.
  3. In your app delegate’s applicationWillEnterForeground: method, your app should call setIsEnteringBackground(false) on the chart.

I’d recommend making sure you’re following these guidelines and see if that removes the crashes you’re seeing. If you do get any more information about the crash or are able to reproduce it yourself, please do let us know.

Kind regards,

Alison


#7

Thanks, I’ll make the changes according to your suggestions and once I ship the app, I’ll let you know about the results.

Just a note to your suggestion - it’s not a good idea to combine applicationWillResignActive with applicationWillEnterForeground - these two aren’t guaranteed to be called in pair. For instance, when you double-click the home button while the app is running then only applicationWillResignActive is called and if after that you select the app from the app switcher again, only applicationDidBecomeActive is called which skips applicationWillEnterForeground call and in this case, based on your advice, the call of setIsEnteringBackground(false) would be skipped. If you are relying on this behaviour in your code, you should fix it and also update your documentation.


#8

Thanks @techet - that’s an interesting point. Our recommendations are based on Apple’s own recommendations in the doc I linked in my previous post, which are contradicted by their own docs on What to do at launch time - perhaps they need to update their docs too? :slight_smile: We don’t rely on this behaviour in our code, but we’ll bear it in mind when adding these recommendations into our docs.


#9

OK, I’m afraid I still get the crash from time to time even after implementing the suggestions. I still think it’s somehow related to the background execution. I’m using Shinobi inside UITableViewCell and I suspect iOS reloads the table in the background under some very rare conditions (and I’m really making sure it’s not me and that I stop all refreshes when entering background). As I said, the crash happens very rarely and it’s not a big issue.


#10

Thanks for the update. If you do find out anything further that would help us to reproduce it, please let us know.