1

I am trying to run the following C program on an SoC platform (baremetal application).

I have a couple of string arrays, defined as

char *init_array[] = { "foo", "bar bar" }

I know this works as an array of char arrays : *init_array[0] returns the 'f' character, init_array[0] returns the first address of "foo" and &init_array[0] returns the adress where the first address of "foo" is saved. The program I work with is based on that definition, so I am not supposed to change it.

Those arrays are going into a loop, in which there may or may not occur an external alteration. At the following iteration, the array must not carry the 'error'.

One of the solutions I've got was to keep two copies of those arrays, the ones I'm gonna use and ones that will initialize them.

Obviously, this has to be "safe-copied", in order to avoid using the same addresses. I have achieved this, with the following code:

char *my_array[2];

for (int i = 0; i < 2; i++) {

        my_array[i] = malloc(strlen(init_array[i]) + 1);

        memcpy(my_array[i], init_array[i],
                strlen(init_array[i]) + 1);

    }

The use of malloc() here (which I would rather avoid, if it's possible) demands the use of free() at the end of every iteration:

for (int i = 0; i < 2; i++) {

// i know it crashes somewhere here

    free(my_array[i]);
    my_array[i] = NULL; //this is supposed to tackle the issue of the same pointer being freed twice(?)

And it works perfectly, for a small number of iterations. Then, the program crashes, and I have to reset the platform I'm working on. As I mention above, I know it crashes somewhere in the last loop. I've also read that:

Crashes in malloc(), calloc(), realloc(), or free() are almost always related to heap corruption, such as overflowing an allocated chunk or freeing the same pointer twice.

I really can't figure out what I'm doing wrong. Is this a heap corruption issue and how can I handle it or am I wrong from the start?

Snoops
  • 11
  • 2
  • 6
    A very likely case of issues are those "external alterations" which you aren't showing – UnholySheep Apr 16 '21 at 13:52
  • Why would you copy strlen + 1? – Irelia Apr 16 '21 at 13:56
  • `my_array[i] = NULL;` doesn't hurt, but it's not really needed. – anastaciu Apr 16 '21 at 13:58
  • @Nina complicated version of `strcpy()` – Ingo Leonhardt Apr 16 '21 at 13:58
  • 1
    Well I don't see anything wrong with the code but it's generally good practice to zero out your arrays after you allocate. – Irelia Apr 16 '21 at 14:03
  • If you suspect malloc (I don't have the full code so I can't see it, I would use alloca (on stack) if you can and separate it to another function so that the frame will end and there will be no memory leak or heap corruption – ArBel Apr 16 '21 at 14:05
  • 2
    what you have seems fine BUT are you sure the "external alterations" don't change the pointers in my_array to different pointers, maybe string literals? – user253751 Apr 16 '21 at 14:08
  • 2
    @Snoops As for me then I have understood nothing. What is the purpose of these manipulations?! Provide a minimal complete program that demonstrates the problem. – Vlad from Moscow Apr 16 '21 at 14:11
  • The external alteration is a bit flip on a random address of &my_array address range. My first thought was that it changes to an adress that I'm supposed to free() later on the loop, hence it was a free-same-pointer issue, but that wasn't the case. – Snoops Apr 16 '21 at 14:12
  • 2
    @Snoops: a random bit flip will likely change one of the pointers to an invalid pointer, which then crashes when you try to free it. – Chris Dodd Apr 16 '21 at 16:27
  • 1
    How do you limit the bit flips to the size of the strings? If you don't, the bit flips will damage all kind of stuff, including memory managing values. `malloc()` returns a pointer to the space with the requested size, but you shall not touch a byte before or after that. – the busybee Apr 16 '21 at 19:03

0 Answers0