Problems updating pointer doing realloc using a structure [duplicate]

Question

I'm trying to create a self-expanding array of a structure. I saw the questions here, here and here but the answers didn't seem to apply to my situation.

I have had pretty good luck using this technique using an array of strings, but using a structure doesn't work. Below is the code:

//  SO1.h
//
#pragma once

typedef struct {
    int tag;
    int type;
}structure;

void addElement(structure* Tkn_A, const int Tag);

void listArray();

Here is the C code.

// SO1.cpp : This file contains the 'main' function. Program execution begins and ends there.
//

#include "stdio.h"
#include "malloc.h"
#include "SO1.h"

const int   ARRAY_INITIAL_SIZE = 2;
const int   ARRAY_ADDITIONAL_SIZE = ARRAY_INITIAL_SIZE / 2;
structure* userArray;
size_t userArrayLength = -1;
size_t userArrayAvailable = ARRAY_INITIAL_SIZE;

int main()
{
    userArray = (structure*)malloc(userArrayAvailable * sizeof(structure));
    printf(" orgarrptr=%p\n", userArray);

    addElement(userArray, 13);
    addElement(userArray, 14);
    addElement(userArray, 15);
    addElement(userArray, 16);
    addElement(userArray, 17);
    addElement(userArray, 18);
    addElement(userArray, 19);
    addElement(userArray, 20);
    addElement(userArray, 21);
    addElement(userArray, 22);
    addElement(userArray, 23);
    addElement(userArray, 24);
    addElement(userArray, 25);
}

void addElement(structure* userArray, const int tag)
{
    userArrayLength++;
    if (userArrayLength > userArrayAvailable) {
        userArrayAvailable += ARRAY_ADDITIONAL_SIZE;
        structure* originalUserArrayPtr = userArray;
        printf(" orgarrptr=%p\n", originalUserArrayPtr);
        userArray = (structure*)realloc(userArray, userArrayAvailable * sizeof(structure));
        printf(" newarrptr=%p\n", userArray);
        if (originalUserArrayPtr != userArray) {
            printf("pointers different\n");
        }
    }
    userArray[userArrayLength].tag = tag;
    userArray[userArrayLength].type = 1;

    printf("%2d   %d\n\n", userArray[userArrayLength].tag,
        userArray[userArrayLength].type);

    listArray();
}

void listArray()
{
    for (size_t i = 0; i <= userArrayLength; i++) {
        printf("%2d   %d\n", userArray[i].tag,
            userArray[i].type);
    }
}

When the program doesn't complete normally, I get the following error on the line doing the realloc:

Debug Assertion Failed!

File: minkernel\crts\ucrt\src\appcrt\heap.cpp
Line: 604

Expression _CrtIsValidHeapPointer(block)

This happens when the realloc comes up with a different pointer than the original with a new length. But the next time I look at the pointer, it still has the value of the old pointer. Below is the output of one run:

:
:
:
13   1
14   1
-842150451   -842150451
-842150451   -842150451
-842150451   -842150451
-842150451   -842150451
-842150451   -842150451
20   1
 orgarrptr=015C79E0
 newarrptr=015C79E0
21   1

13   1
14   1
-842150451   -842150451
-842150451   -842150451
-842150451   -842150451
-842150451   -842150451
-842150451   -842150451
-842150451   -842150451
21   1
 orgarrptr=015C79E0
 newarrptr=015C5F58        <===  new pointer
pointers different
22   1

13   1
14   1
-842150451   -842150451
-842150451   -842150451
-842150451   -842150451
-842150451   -842150451
-842150451   -842150451
-842150451   -842150451
21   1
-1863261150   134281082
 orgarrptr=015C79E0        <===  original pointer


exited with code 3.

Does anyone know what would cause this problem? TIA.

Sorry for the long question, but I wanted to give out all the details. I don't think Visual Studio has anything to do with problems, but don't know for sure. I'm using VS Community Edition 2019, 16.1.3.

Update: Originally I had two problems. One getting the pointer updated and the other getting garbage data. I decided to split the two into two different questions.

void addElement(structure* userArray, const int tag) works inside on the local variable userArray but no on the global variable userArray as you might expect. (The latter is eclipsed by the former inside the function.) Hence, whenever realloc() returns a new address, it gets lost as soon as you leave the function while the global userArray is kept unchanged. You could eliminate parameter userArray from addElement(). However, I would recommend to return userArray (changing the return type to structure*) and assign result of addElement() to the global again. — Scheff's Cat
– Scheff's Cat, Commented Jun 30, 2019 at 7:55
In addition to the excellent answer of @Scheff, I think that, considering the capability of the function addElement to manage different allocations of the structure structure, it's better to manage the element counter (userArrayLength) in an other way. In the actual way you may manage only one array because the counter is managed using only one variable (userArrayLength). A simple way should be to pass the counter pointer to the addElement and the to the listElement functions. — Sir Jo Black
– Sir Jo Black, Commented Jun 30, 2019 at 8:50
@AnttiHaapala I hadn't expected such duplicate as the issue has actually less to do with realloc() but more with scopes and eclipsing. Respect. ;-) — Scheff's Cat
– Scheff's Cat, Commented Jun 30, 2019 at 9:08

Scheff's Cat · Accepted Answer · 2019-06-30 08:30:41Z

3

IMHO, the OP is not yet aware about scopes of variables:

void addElement(structure* userArray, const int tag)
{
  /* The global variable userArray is now invisible (eclipsed).
   * Instead, the local parameter userArray is used.
   * It has its own storage.
   */
}

Hence, whenever realloc() returns a different address then given it gets lost after leaving addElement().

realloc() may return

the given address (of first argument)
a new address
a NULL pointer.

The heap managment which is used inside of realloc() might recognize that memory after block to grow is still free. Hence, the block can be grown in place. It might also be the case that the heap management provided earlier a larger block than actually requested. (This could be a strategy to prevent fragmentation of heap memory.) This is the reason why same address might be returned although more memory than before was requested.

If nothing of above was applicable a new block is allocated, old contents copied to new address, and old block is freed. (Otherwise, it would become a memory leak.)

If realloc() fails to do any of the above, it returns NULL.

Recalling the above, it's even worse: Whenever realloc() returns a different address then the memory at old address is freed. So, the global userArray (which is not updated) becomes dangling (pointing to freed memory). Accessing a dangling pointer is Undefined Behavior → good for any strange effects including a crash (Access Violation).

Concerning the third:

userArray = (structure*)realloc(userArray, userArrayAvailable * sizeof(structure));

might appear questionable.

(My personal thinking about this is: When memory is exceeded this means usually things have gone very wrong. The process has usually to be terminated as soon as possible. This will happen on most platforms when a NULL pointer is accessed ignoring the fact that the ugly system error message might scare the user and force her/him to make a support call. And, please, note my repeated usage of "usually"...)

The OP already observed the points 1. and 2. in diagnostic output.

There are various options to fix this issue:

get rid of the global variable eclipsing:

void addElement(const int tag)
{
  /* unmodified code will now access the global userArray */
}

use a pointer to pointer instead:

void addElement(structure **userArray, const int tag)
{
  /* all uses of userArray in code have to get an additional indirection operator
   * i.e. replace all occurrences of "userArray" by "(*userArray)"
   */
}

return (potentially changed) userArray as result:

structure* addElement(structure *userArray, const int tag)
{
  /* unmodified code */
  return userArray;
}

has to be called now:

userArray = addElement(userArray, 13);

to reassign the (potentially changed) pointer to global variable.

I (personally) prefer design 3 in general. However, considering that addElement() accesses a variety of other global variables as well option 1 seems to me the most consistent fix.

edited Jun 30, 2019 at 8:30

answered Jun 30, 2019 at 8:21

Scheff's Cat

20.4k6 gold badges34 silver badges63 bronze badges

Sign up to request clarification or add additional context in comments.

3 Comments

Sir Jo Black Over a year ago

In addition to your excellent answer, I think that, considering the function addElement capability (if the method 2 or 3 will used) to manage different allocations of the structure (structure), it's better to manage the element counter (userArrayLength) in an other way. In the actual way the code may manage only one array because the counter is managed using only one variable (userArrayLength). A simple way would be to pass the counter pointer to the addElement and the counter to the listElement functions.

Scheff's Cat Over a year ago

@SirJoBlack I fully agree. I'm afraid the answer is even long as it is. (I'm not yet good in the art of short answers.) So, I left an upvote on your comment...

Anonymoose Over a year ago

@Scheff: Thank you so much for the long and considerate answer. I went with option 3 and the problem is resolved. Thanks again.

Collectives™ on Stack Overflow

Problems updating pointer doing realloc using a structure [duplicate]

1 Answer 1

3 Comments

Linked

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

3 Comments

Linked

Related