Integer object will have possibility of null value

You say you think it contains some specific information. Do you have any promise anywhere that tells you this is so? Or any indication at all? If you look at the example code you can see how it is used. It does not put this length information there, or any other information, but the parameter is used, what's done with it?

Not required to answer that, but so that you have the full code - this is the preloaded function:
(and if anyone's feeling trigger happy on the spoiler button - don't. there is nothing secret in this.)

char* array2StringData(Pair** arr, int sz) {
    if (sz == 0) {free(arr); return "{}";}
    // for each pair length of 2 int + { + } +", " + 1
    int lgs = 0;
    for(int i = 0; i < sz; i++) {
        lgs += 10 + 10 + 5;
    }
    char *dest = (char*)calloc(1, sizeof(char) * lgs + 1);
    char *p = dest;
    *p++ = '{';
    for(int i = 0; i < sz; i++) {
        sprintf(p += strlen(p), "{%lld, %lld}", arr[i]->first, arr[i]->snd);
        //free the pair
        free(arr[i]); arr[i] = NULL;
    }
    // free array of pairs
    free(arr);
    int l = strlen(dest);
    dest[l] = '}'; dest[l + 1] = '\0';
    return dest;
}

Reconsider what the length param is for. What promises are you given about it, how is it used in the test code?

With preloaded hidden or visible, it does not matter. Allocation scheme required for this kata is terrible, counterintuitive, and against every existing C rule.
Bonus points for designig a stringification function in a way it invalidates the stringified array. Yay.

I solved it just now as a C novice. I blame preload above all else - making it difficult to reproduce locally.
It wasn't enough to copy the test cases, I needed to reproduce the free's as well... Part of the API was hidden.

For C, the result is expected to be a dynamically allocated array of pointers to dynamically allocated individual pairs, which is beyond ridiculous.

I hope one day some update to C runner would render all C kata invalid, and force C authors to fix every translation they created in such a twisted, FUBAR shape like this one.

Now the question would be, will author fix the kata, or they will leave it broken "because solutions".

Call it and find out? But I imagine that since you're providing a location to read from, it would read from that location regardless of where it is. It wouldn't matter, would it?

I do wonder why you're talking specifically about dynamic/static allocation. Is this something you tested where you found one to work and the other not? Because if not then you have no indication that this is what it's about.

Getting a result of {} would mean that the array was never looked at at all, wouldn't it? The array itself would have no effect on this. What has an effect on this?

That global variable is what creating the problem, you've to properly reset them in order for the next call.

And this code appears to work in codeblocks because you might be testing only for the argument in whichh your code fails here.

Yes you may, but you should post your code with proper markdown and please remember to use the spoiler tag.

The usual cause for "works for me but not here" is to not test the same thing, for example using a different test case or no test cases at all.
Since you're using C, there's another likely cause: undefined behaviour. Make sure you're not relying on something that isn't supported by the C standard. One of the more common things in that department is to use uninitialized memory.
You can probably find out what happens with some well chosen printf's.

It depends on what combinationUtil is and where it comes from.

is there a possibility to delete one of them?

No.

Or is it once there always there, so as to discourage some sort of dishonest practices maybe?

I'm not sure, maybe it's that way.