Pointer to uninitialized pointer, CRASH?

**legendbb** · 06-21-2019

Dear all,

I'm troubleshooting an ARM-A53 baremetal embedded system code. There is no memory management unit.

While the following code 100% certain generates a "synchronous abort".

Code:

int Var;
int *pVar;
int **ppVar = &pVar; // CRASH 100% with pVar = 0x0

func_call(ppVar); // to extract some global variable updated in func_call;

// I can make code work by doing, but I want to understand why above method fails 100% of time.
// func_call(&pVar);

I understand when "pVar = 0x0" it crashes, but why it's 100%, isn't uninitialized pointer supposed to be random?

Please comment,

Thanks!

**laserlight** · 06-21-2019

You initialised it to be a null pointer, so it most certainly isn't pointing to anything valid, whereas if it is a non-null pointer it may or may not be pointing to something valid.

**Niccolo** · 06-21-2019

To be clear, you are asking why undefined behavior has random results.

To understand the "why" of this, one would have to understand exactly what func_call does. If, for example, you write an empty function I'd expect the func_call would not crash, right?

So.....it depends entirely on what func_call actually does as to the "why" of things.

Here's a theory, wild speculation to be sure.

Notice that when the stack makes room for int *pVar, it is followed by another entry for **ppVar, which takes up some little space. If, and here's speculation, the "thing" that func_call does actually ends up writing over the space occupied by ppVar (when you pass &pVar), it could be "protected" by the fact that this unused space is a "safety zone" protecting the call. When you pass ppVar, on the other hand, now you've used that space. Maybe now things are different, the stack "alignment" is off, and behavior is entirely different. Perhaps the stack was corrupted in this alternative version, and has nothing to do with the code you posted.

Again, this is pure speculation - it is, however, the nature of this kind of thing. You're posing why some genuinely nonsensical code (that couldn't possibly really work correctly) somehow works one way but not another.

It may be an interest intellectual exercise, and is the kind of thing people do to make viruses, but I doubt it's all that informative.

What happens if, before you get to ppVar, you set pVar = &Var?

At least it's pointing to something reasonable, but does that cause this to fail, too?

**legendbb** · 06-21-2019

Thanks for comments, with all your inputs. I think I got to "uninitialized pointer vs NULL pointer", I was expecting pVar being uninitialized not NULL. The mistake is to assign the uninitialized into a "pointer of pointer". Crash happens right here before "func_call()", but @Niccolo, I like your theory of stack overflow.

I was really puzzled was, in this location, pVar is always 0x0 (causing CPU into "Synchronous Abort"). But same code in various other locations works without crash, random non-zero values.

I know I'm violating good practice, and trying to get a good principle of using "pointer of pointer". That seems to me: never assign address of a uninitialized pointer to a pointer of pointer.

**laserlight** · 06-21-2019

Originally Posted by legendbb

I know I'm violating good practice, and trying to get a good principle of using "pointer of pointer". That seems to me: never assign address of a uninitialized pointer to a pointer of pointer.

You can follow such a rule, but there are cases when there isn't much use in say, initialising a pointer to be a null pointer because you are immediately going to pass its address to a function that will provide the actual initial value. Hence, I personally do not follow such a rule, but rather I declare variables near first use such that I can provide them with a sensible initial value, either through initialisation or soon after declaration say through a function call.

If you do want to follow the rule to never assign address of a uninitialized pointer to a pointer of pointer even when you don't need to, then why limit this to pointers? You would be inconsistent. I would suggest a more general rule: never assign the address of anything unitialised to a pointer, e.g., if you want to call scanf to read an int, you will not write:

Code:

int x;
if (scanf("%d", &x) == 1)

but rather:

Code:

int x = 0;
if (scanf("%d", &x) == 1)

The initialision of x to 0 would be pointless here since you will not use x unless the scanf assignment to x succeeds, but it would be consistent and hence help you avoid cases where it is not pointless but you forgot. That is, either you always take care to do the right thing (e.g., pass the address of an initialised pointer when needed, or not when not needed), or if you want to be paranoid about not doing the wrong thing, then be paranoid everywhere or your inconsistency will come back to bite you.

**Niccolo** · 06-21-2019

inconsistency will come back to bite you

Make that a poster or wallpaper!

**legendbb** · 06-24-2019

Great thanks!

Thread: Pointer to uninitialized pointer, CRASH?

Thread Tools

Search Thread

Display

Pointer to uninitialized pointer, CRASH?

Similar Threads

Null pointer vs uninitialized pointer

crash program pointer

Uninitialized pointer usage: one OK, other NOK?

How To Chk Uninitialized Pointer

deferencing uninitialized pointer

Tags for this Thread