Operating System - HP-UX
1752794 Members
6329 Online
108789 Solutions
New Discussion юеВ

SEGV_ACCERR - Invalid Permissions

 
SOLVED
Go to solution
ASR
Contributor

SEGV_ACCERR - Invalid Permissions

Hi,
Below code getting core dump on Itanium 11.31 with cc and aCC. Can anybody help.

#include
int main()
{
char *array[] = { "0", "0", "0", "0" };
short i;
for (i=0; i < 4; i++)printf("array[i] = %s \n",array[i]);
for (i=0; i < 4; i++)array[i][0] = '0';
printf("i= %d \n",i);
return 0;
}

$ aCC +DD64 -g -Ae sigfault.c -o sigfault
$ ./sigfault
array[i] = 0
array[i] = 0
array[i] = 0
array[i] = 0
Memory fault(coredump)

Core was generated by `sigfault'.
Program terminated with signal 11, Segmentation fault.
SEGV_ACCERR - Invalid Permissions for object
#0 0x4000000000000d00:0 in main () at sigfault.c:7
7 for (i=0; i < 1; i++)array[i][0] = '0';
7 REPLIES 7
Jeeshan
Honored Contributor

Re: SEGV_ACCERR - Invalid Permissions

see this wiki

http://en.wikipedia.org/wiki/SIGSEGV
a warrior never quits
Dennis Handly
Acclaimed Contributor

Re: SEGV_ACCERR - Invalid Permissions

Your code is illegal you must recode your program. You should be getting a nasty warning on: char *array[] = { "0", "0", "0", "0" };
You are trying to modify read only strings.

Take a look at the Release Notes to see how to declare a char *array[]:
http://docs.hp.com/en/5992-1714/ch02s01.html#d0e473
char tmp0[] = "0";
char tmp1[] = "0";
char tmp2[] = "0";
char tmp3[] = "0";
char *array[] = { tmp0, tmp1, tmp2, tmp3 };

Matti_Kurkela
Honored Contributor

Re: SEGV_ACCERR - Invalid Permissions

The line

char *array[] = { "0", "0", "0", "0" };

defines an array of pointers to literal strings, or in other words _string constants_. The individual strings are unnamed, but they are still treated as constants.

The compiler *may* store the string constants into an area of memory that is read-only at execution time. Apparently this compiler does that.

Your first loop displays the four string constants without a problem. The second loop tries to write to the first character of each string - but the string constants are stored in a memory location that is not writable by your program. The MMU of the processor detects the memory access violation and causes a signal 11. The OS stops the program execution and dumps its memory image into a core file.

If you want an array of 4 variable strings, you must explicitly say so, and you must specify the maximum length of the strings. In this example, the length of each string can be 2 characters: the character '0' and the string terminator character '\0'.

So, you'll want to declare your array as:

char array[4][2] = { "0", "0", "0", "0" };

Here, the string constants are used as initialization values only. The array variable is created, and the string constants are _copied_ into the array. The difference is subtle, but it is there.

MK
MK
Matti_Kurkela
Honored Contributor

Re: SEGV_ACCERR - Invalid Permissions

Dennis, as far as I understand, the declaration

char *array[] = { "0", "0", "0", "0" };

is still legal C. That *is* the way to declare an array of pointers to string constants. What is illegal is trying to modify the string values after a declaration like this.

Changing the values of the pointers to point to different (possibly variable) strings is still legal. If necessary, that could be prevented by prepending the declaration with "const".

Enforcing the "constant-ness" of a string constant in C at compile-time would require a fairly intensive semantic analysis of the program.

The question would be: "Will any pointer that is used to determine a target of a write operation point to this constant in any possible execution of this program?"

Off the top of my head, I'd estimate such an analysis for all possible programs would be essentially equivalent to the famous Halting Problem.

Fortunately the compiler does not need that kind of an analysis to produce a valid program. The constants can easily be enforced at runtime by storing them in a read-only location.

In short: a C compiler may certainly be able to warn about *some* attempts to write into a constant at compile-time, but it's unreasonable to expect it to warn about *all* possible such attempts. This is why constants should be enforced at run-time, and many environments do exactly that.

MK
MK
Dennis Handly
Acclaimed Contributor

Re: SEGV_ACCERR - Invalid Permissions

>MK: as far as I understand, the declaration
char *array[] = { "0", "0", "0", "0" };
is still legal C.
>What is illegal is trying to modify the string values after a declaration like this.

Didn't I say that? :-)
Yes, illegal when combined with the store into those strings. This is the same as:
char *array[] = { (char*)"0", (char*)"0", (char*)"0", (char*)"0" };

And whether you can cast away hardware constness is implementation defined. And that's where the signal 11 occurs.

>Changing the values of the pointers to point to different (possibly variable) strings is still legal.

That's not what was done. ASR tried to change the strings.

>If necessary, that could be prevented by prepending the declaration with "const".

Yes, that should have been done.

>Enforcing the "constant-ness" of a string constant in C at compile-time would require a fairly intensive semantic analysis of the program.

No need to. Just a simple warning saying that you should NOT assign string literals to char*.

>"Will any pointer that is used to determine a target of a write operation point to this constant in any possible execution of this program?"

Using +wlint and +O2 may already do that.

>I'd estimate such an analysis for all possible programs would be essentially equivalent to the famous Halting Problem.

Yes but not in this case of a single function.

>The constants can easily be enforced at runtime by storing them in a read-only location.

That's what it does by default.

>a C compiler may certainly be able to warn about *some* attempts to write into a constant at compile-time

A C compiler can warn about CV typesafety violations.

And in C++ it is deprecated/illegal unless there is a cast and then it is the user's problem.
ASR
Contributor

Re: SEGV_ACCERR - Invalid Permissions

Thanks a ton!!!
Dennis Handly
Acclaimed Contributor
Solution

Re: SEGV_ACCERR - Invalid Permissions

If you are happy with our answers, please read the following about assigning points:
http://forums.itrc.hp.com/service/forums/helptips.do?#33