Make sure group_list is deallocated on finalisation

[trdurrant]

Resolve #383

[jeffhammond]

How does setting the pointer to null guarantee deallocation? It's not deallocating, it merely guarantees memory is leaked if the pointer isn't deallocated already.

[bjpalmer]

The group_list variable is just a pointer to the head of a linked list that should have been cleaned up in the previous while loop. Setting it to NULL doesn't do much.

[trdurrant]

It was a poor choice of words on my part to use the word deallocate, I apologise for the sloppy language I used. I mostly program in Python and Fortran, and I don't have as much experience with C or pointers as I would like.

I thought that nullifying the group_list pointer is a required step of finalisation in this context, otherwise I thought that the following assertion in the initialiser will fail on subsequent attempts to initialise:

ga/comex/src-mpi-pr/groups.c

Line 525 in 6534d14

COMEX_ASSERT(group_list == NULL);

The group_list pointer is set to null here in the finalisation of the MPI-TS mode:

ga/comex/src-mpi/groups.c

Line 291 in 6534d14

group_list = NULL;

so it seemed like this could be related to the different behaviour observed between the two modes.

I may well be making a mistake, but from my own testing it did appear that the example code #383 will run with this MR, but will return an error without it.

But it is true that if there are memory leaks in the finalisation function, it will become a more serious problem if repeat initialisations are used. It looks like some memory is being deallocated in the finalisation block as it presently stands, but it could well be incomplete and I don't understand the MPI-PR code well enough to know

[bjpalmer]

Hmm. Missed that assert. The pointer group_list is a global variable that is initialized to NULL at the top of the groups.c file but if the comex_group_init function is called more than once, then you could run into problems if group_list is not set to NULL. There is no issue with setting it equal to NULL in the comex_group_finalize call since it is never directly allocated memory. A link in the group linked list is created and then the group_list is set to that link. If the link is freed, which happens int the while loop in comex_free_finalize, then the data pointed to by group_list is cleaned up and there is no leak.