35

I am examining a few crashes that all have the signal SIGSEGV with the reason SEGV_ACCERR. After searching for SEGV_ACCERR, the closest thing I have found to a human readable explanation is: Invalid Permissions for object

What does this mean in a more general sense? When would a SEGV_ACCERR arise? Is there more specific documentation on this reason?

Saltymule
  • 2,907
  • 2
  • 22
  • 30
  • 4
    [This](http://lxr.free-electrons.com/source/include/uapi/asm-generic/siginfo.h#L201) in the source says it means "Invalid permissions for mapped object". I'm guessing that means that you are trying to do something to an mmaped region that you arn't allowed to do. – Linuxios Oct 01 '13 at 15:18
  • 3
    Does this help?? http://h30499.www3.hp.com/t5/Languages-and-Scripting/SEGV-ACCERR-Invalid-Permissions/td-p/4241252#.UkroZ4akzzI – Rahul Tripathi Oct 01 '13 at 15:22
  • 1
    Why do you need to know this? Do you experience strang crashes of a program? In case yes, check the way it handles memory, probably run it using a memory checker like for example Valgrind: http://valgrind.org – alk Oct 01 '13 at 17:30
  • What platform are you seeing this on? – Doug Richardson Feb 18 '14 at 23:36
  • @DougRichardson This is still happening in my app on ios devices. The crash reports are coming into crittercism. There is very little context to what is causing these crashes. – Saltymule Mar 03 '14 at 13:18
  • I meant what platform is your code running on: OS X or iOS. – Doug Richardson Mar 05 '14 at 21:21
  • 4
    For your information, I usually see `CFNetwork` framework crash with `SEGV_ACCERR` code when the device runs out of memory. – murat Mar 20 '14 at 09:04

5 Answers5

17

This is an error that I have mostly seen on 64 bit iOS devices and can happen if multiple threads read and change a variable under ARC. For example, I fixed a crash today where multiple background threads were reading and using a static NSDate and NSString variable and updating them without doing any kind of locking or queueing.

Using core data objects on multiple threads can also cause this crash, as I have seen many times in my crash logs.

I also use Crittercism, and this particular crash was a SEGV_ACCERR that only affected 64 bit devices.

jjxtra
  • 20,415
  • 16
  • 100
  • 140
  • Do you know of any documentation? Invalid Permissions for object seems like a good fit for what you are describing. – Saltymule Sep 17 '14 at 15:50
  • @Dan_Gabicoware I don't know of any documentation, just seems logical to me. We have had multiple SEGV_ACCERR crashes, and all of them seem to be bad pointer problems / core data issues on only 64 bit devices. – jjxtra Sep 17 '14 at 15:51
  • 1
    In our crittercism logs, this crash (or versions of this crash) are not unique to 64-bit devices. In fact, one of the versions is exclusively on older hardware, ending at the ipad 3. The other one is on all hardware. Both of them are exclusively ios 8, though, whereas other crashes span a wide range of older ios versions. – puzzl Jan 22 '15 at 21:51
10

As stated in the man page of sigaction, SEGV_ACCERR is a signal code for SIGSEGV that specifies Invalid permissions for mapped object. Contrary to SEGV_MAPERR which means that the address is not mapped to a valid object, SEGV_ACCERR means the address matches an object, but for sure it is neither the good one, nor one the process is allowed to access.

germinolegrand
  • 166
  • 1
  • 6
  • 8
    Don't be confused: "Object" in this case doesn't mean a Swift or Obj-C or C++ object, it means a kernel memory object, i.e. a range of address space. The error means that something tried to use a memory address in a way that's not allowed, i.e. writing to read-only memory or executing code from non-executable memory. – Jens Alfke Jul 01 '19 at 19:28
5

I've seen this in cases where code tries to execute from places other than "text".

For eg, if your pointer is pointing to a function in heap or stack and you try to execute that code (from heap or stack), the CPU throws this exception.

Sameer
  • 51
  • 1
  • 1
  • so youtube was [trying](https://github.com/ungoogled-software/ungoogled-chromium-archlinux/issues/28) to hack me through chromium?! :) –  Sep 22 '19 at 00:04
2

It's possible to get a SEGV_ACCERR because of a stack overflow. Specifically, this happened to me on Android ARM64 with the following:

VeryLargeStruct s;
s = {}; // SEGV_ACCERR

It seems that the zero-initialization created a temporary that caused a stack overflow. This only happened with -O0; presumably the temporary was optimized away at higher optimization levels.

Joseph Thomson
  • 9,888
  • 1
  • 34
  • 38
2

On android arm64 if stack.cpp contains:

struct VeryLargeStruct  {
    int array[4096*4096];
    };
int main() {
    struct VeryLargeStruct s;
    s = {}; 
    }

and typing:

aarch64-linux-android26-clang++  -std=c++20 -g -DANDROID_STL=c++_static -static-libstdc++ stack.cpp -o stack
adb push stack /data/local/tmp
adb shell  /data/local/tmp/stack

/data/tombstones/tombstone_01 contains a SEGV_MAPERR, not SEGV_ACCERR:

id: 11363, tid: 11363, name: stack  >>> /data/local/tmp/stack <<<
signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x7ff2d02dd8

I get SEGV_ACCERR, when const.c contains:

int main() {
    char *str="hello";
    str[0]='H';
    }

Then /data/tombstones/tombstone_00 contains:

pid: 9844, tid: 9844, name: consts  >>> /data/local/tmp/consts <<<
Signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x55d10674e8
jka
  • 21
  • 1
  • 1