How to interpret crash reason


dhoerl
 

I am getting a steady dribble of crashes that look like this, but all slightly different:

Recording key: jgWdIxY2BxSvsSnxQnwH
Issue type: Crash
Issue created: Wed Oct 28 2020 03:52:32 GMT-0400 (EDT)
Issue summary: SIGSEGV(SEGV_ACCERR) at pthread_mutex_lock$VARIANT$armv81 + 0
Issue description:
=====
SEGV_ACCERR
=====
Total recordings: 12
Total users: 6
Total events: 37

Thread 0 Crashed:
Thread #0:
0 pthread_mutex_lock$VARIANT$armv81 + 0
1 IOSurfaceClientSetValue + 100
2 FigPhotoCreateImageSurface + 160
3 FigPhotoSurfacePoolCreateImageSurface + 2212
4 _createPixelBufferFromJPEG + 2028
5 FigPhotoJPEGCreateIOSurfaceFromJPEG + 332
6 AppleJPEGReadPlugin::createIOSurfaceWithHardware_aspen(CGImageProvider*, __CFData const*, unsigned int, __IOSurface**) + 260
7 AppleJPEGReadPlugin::CopyIOSurfaceProc(void*, CGImageProvider*, __CFDictionary const*) + 1796
8 IIOImageProviderInfo::CopyIOSurface(void*, CGImageProvider*, __CFDictionary const*) + 648
9 CA::Render::copy_image(CGImage*, CGColorSpace*, unsigned int, double, double) + 1908
10 CA::Render::prepare_image(CGImage*, CGColorSpace*, unsigned int, double) + 16
11 CA::Layer::prepare_commit(CA::Transaction*) + 492
12 CA::Context::commit_transaction(CA::Transaction*, double) + 304
13 CA::Transaction::commit() + 672
14 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 88
15 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 28
16 __CFRunLoopDoObservers + 416
17 __CFRunLoopRun + 964
18 CFRunLoopRunSpecific + 420
19 GSEventRunModal + 156
20 UIApplicationMain + 1928
21 main (AppDelegate.swift:72)
22 start + 0

What I don't understand is:

SIGSEGV(SEGV_ACCERR) at pthread_mutex_lock$VARIANT$armv81 + 0

That is the common element. How should I understand this?

Thanks!

David


 



On Oct 28, 2020, at 6:53 AM, dhoerl via groups.io <dhoerl@...> wrote:

SIGSEGV(SEGV_ACCERR) at pthread_mutex_lock$VARIANT$armv81 + 0

SEGV_ACCERR means a crash where the address exists [is mapped] but doesn't allow that type of access. Usually it means something tried to write to a read-only address, but it could also mean trying to execute code from a page not mapped as executable.

My first thought is that the caller (IOSurfaceClientSetValue) is locking a mutex at a garbage address that happens to exist but is read-only.

But it's weird that there's no address given in the log, only the name of the function; if the crash really is at that address, it would mean that the page the function's on is not executable. But that doesn't make any sense.

In any case, it looks like this crash is deep inside a bunch of OS code having to do with JPEG codecs and GPU surfaces, so it's unlikely to involve your code. (Unless "FigPhotoCreateImageSurface" is a function in your app?) I'd submit a bug report to Apple.

—Jens


Gary L. Wade
 

I would first see if you’re using a graphics format or color space not supported on that device.
--
Gary L. Wade
http://www.garywade.com/

On Oct 28, 2020, at 6:53 AM, dhoerl via groups.io <dhoerl=mac.com@groups.io> wrote:

I am getting a steady dribble of crashes that look like this, but all slightly different:

Recording key: jgWdIxY2BxSvsSnxQnwH
Issue type: Crash
Issue created: Wed Oct 28 2020 03:52:32 GMT-0400 (EDT)
Issue summary: SIGSEGV(SEGV_ACCERR) at pthread_mutex_lock$VARIANT$armv81 + 0
Issue description:
=====
SEGV_ACCERR
=====
Total recordings: 12
Total users: 6
Total events: 37

Thread 0 Crashed:
Thread #0:
0 pthread_mutex_lock$VARIANT$armv81 + 0
1 IOSurfaceClientSetValue + 100
2 FigPhotoCreateImageSurface + 160
3 FigPhotoSurfacePoolCreateImageSurface + 2212
4 _createPixelBufferFromJPEG + 2028
5 FigPhotoJPEGCreateIOSurfaceFromJPEG + 332
6 AppleJPEGReadPlugin::createIOSurfaceWithHardware_aspen(CGImageProvider*, __CFData const*, unsigned int, __IOSurface**) + 260
7 AppleJPEGReadPlugin::CopyIOSurfaceProc(void*, CGImageProvider*, __CFDictionary const*) + 1796
8 IIOImageProviderInfo::CopyIOSurface(void*, CGImageProvider*, __CFDictionary const*) + 648
9 CA::Render::copy_image(CGImage*, CGColorSpace*, unsigned int, double, double) + 1908
10 CA::Render::prepare_image(CGImage*, CGColorSpace*, unsigned int, double) + 16
11 CA::Layer::prepare_commit(CA::Transaction*) + 492
12 CA::Context::commit_transaction(CA::Transaction*, double) + 304
13 CA::Transaction::commit() + 672
14 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 88
15 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 28
16 __CFRunLoopDoObservers + 416
17 __CFRunLoopRun + 964
18 CFRunLoopRunSpecific + 420
19 GSEventRunModal + 156
20 UIApplicationMain + 1928
21 main (AppDelegate.swift:72)
22 start + 0

What I don't understand is:

SIGSEGV(SEGV_ACCERR) at pthread_mutex_lock$VARIANT$armv81 + 0

That is the common element. How should I understand this?

Thanks!

David





Alex Zavatone
 

On Oct 28, 2020, at 5:20 PM, Gary L. Wade <garywade@desisoftsystems.com> wrote:

I would first see if you’re using a graphics format or color space not supported on that device.
Gary, you may have something there. I remember getting graphic assets from a third party that had an unexpected colorspace attached to it for a Asus monitor. These caused a crash because of an unexpected colorspace.



--
Gary L. Wade
http://www.garywade.com/

On Oct 28, 2020, at 6:53 AM, dhoerl via groups.io <dhoerl=mac.com@groups.io> wrote:

I am getting a steady dribble of crashes that look like this, but all slightly different:

Recording key: jgWdIxY2BxSvsSnxQnwH
Issue type: Crash
Issue created: Wed Oct 28 2020 03:52:32 GMT-0400 (EDT)
Issue summary: SIGSEGV(SEGV_ACCERR) at pthread_mutex_lock$VARIANT$armv81 + 0
Issue description:
=====
SEGV_ACCERR
=====
Total recordings: 12
Total users: 6
Total events: 37

Thread 0 Crashed:
Thread #0:
0 pthread_mutex_lock$VARIANT$armv81 + 0
1 IOSurfaceClientSetValue + 100
2 FigPhotoCreateImageSurface + 160
3 FigPhotoSurfacePoolCreateImageSurface + 2212
4 _createPixelBufferFromJPEG + 2028
5 FigPhotoJPEGCreateIOSurfaceFromJPEG + 332
6 AppleJPEGReadPlugin::createIOSurfaceWithHardware_aspen(CGImageProvider*, __CFData const*, unsigned int, __IOSurface**) + 260
7 AppleJPEGReadPlugin::CopyIOSurfaceProc(void*, CGImageProvider*, __CFDictionary const*) + 1796
8 IIOImageProviderInfo::CopyIOSurface(void*, CGImageProvider*, __CFDictionary const*) + 648
9 CA::Render::copy_image(CGImage*, CGColorSpace*, unsigned int, double, double) + 1908
10 CA::Render::prepare_image(CGImage*, CGColorSpace*, unsigned int, double) + 16
11 CA::Layer::prepare_commit(CA::Transaction*) + 492
12 CA::Context::commit_transaction(CA::Transaction*, double) + 304
13 CA::Transaction::commit() + 672
14 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 88
15 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 28
16 __CFRunLoopDoObservers + 416
17 __CFRunLoopRun + 964
18 CFRunLoopRunSpecific + 420
19 GSEventRunModal + 156
20 UIApplicationMain + 1928
21 main (AppDelegate.swift:72)
22 start + 0

What I don't understand is:

SIGSEGV(SEGV_ACCERR) at pthread_mutex_lock$VARIANT$armv81 + 0

That is the common element. How should I understand this?

Thanks!

David









Alex Zavatone
 

Looking at the previous comments on this and dredging my memory, if it is possible to use Crashlytics or some service to log the name of the JPEG image being accessed when the crash happens, you may be able to get that image and see if it is a colorspace issue.

You could also add a debug routine to scan all of the JPEGs used and report the string value of their colorspace if this is happening on a remote machine.

From what I remember, both loading the image in Xcode and looking at the inspector for what it thinks the colorspace is as well examining the colorspace in the Preview app were tools I used to track down or rule out colorspace issues.

Cheers.

On Oct 28, 2020, at 8:53 AM, dhoerl via groups.io <dhoerl@...> wrote:

3 FigPhotoSurfacePoolCreateImageSurface + 2212
4 _createPixelBufferFromJPEG + 2028
5 FigPhotoJPEGCreateIOSurfaceFromJPEG + 332


dhoerl
 

Thanks to all who replied to this. The weird thing was that it only happens infrequently  - a user gets it then doesn't for a long time.

So I had an idea - breakpoint on FigPhotoJPEGCreateIOSurfaceFromJPEG - this is an Apple C function in the MediaToolbox. Now, I can at least see what code is using that method, and gee - it turns out to be a piece of code already flagged as buggy!

Just thought I'd share.

David


Alex Zavatone
 

Great!  Any idea what the underlying cause was?  Was it reproducible with certain images, colorspaces, etc?

On Nov 17, 2020, at 12:55 PM, dhoerl via groups.io <dhoerl@...> wrote:

Thanks to all who replied to this. The weird thing was that it only happens infrequently  - a user gets it then doesn't for a long time.

So I had an idea - breakpoint on FigPhotoJPEGCreateIOSurfaceFromJPEG - this is an Apple C function in the MediaToolbox. Now, I can at least see what code is using that method, and gee - it turns out to be a piece of code already flagged as buggy!

Just thought I'd share.

David


dhoerl
 

The explanation on the crappy code is complex - but it has to do with code that scales a large image on background threads, then renders just a tiny piece of that. I think iOS gets overloaded - that code crashes my companies users occasionally, but I've never had it happen to me. So the image itself is fine, and a user who crashes may not get another crash for a long time, or never. Corrupted JPEG was a read herring. 

What I did want to share is that by breakpointing on the one C function that I saw allowed me to determine what piece of code was using that API - and it was just in one place!

David