Thread: Pointer to uninitialized pointer, CRASH?

  1. #1
    Registered User
    Join Date
    May 2010
    Posts
    9

    Question Pointer to uninitialized pointer, CRASH?

    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!

  2. #2
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,162
    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.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  3. #3
    Registered User
    Join Date
    May 2019
    Posts
    209
    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?

  4. #4
    Registered User
    Join Date
    May 2010
    Posts
    9
    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.
    Last edited by legendbb; 06-21-2019 at 07:22 PM.

  5. #5
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    27,162
    Quote Originally Posted by legendbb View Post
    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.
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #6
    Registered User
    Join Date
    May 2019
    Posts
    209
    inconsistency will come back to bite you
    Make that a poster or wallpaper!

  7. #7
    Registered User
    Join Date
    May 2010
    Posts
    9
    Great thanks!

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Null pointer vs uninitialized pointer
    By Abhishek Kumar in forum C++ Programming
    Replies: 23
    Last Post: 03-05-2014, 12:01 PM
  2. crash program pointer
    By mohsen in forum C Programming
    Replies: 10
    Last Post: 07-05-2013, 12:47 PM
  3. Uninitialized pointer usage: one OK, other NOK?
    By courteous in forum C Programming
    Replies: 7
    Last Post: 04-20-2010, 05:17 AM
  4. How To Chk Uninitialized Pointer
    By u_peerless in forum C Programming
    Replies: 11
    Last Post: 06-19-2008, 10:11 AM
  5. deferencing uninitialized pointer
    By Bontrey in forum C Programming
    Replies: 7
    Last Post: 02-21-2008, 12:48 AM

Tags for this Thread