Memory leak when using the @disable macro

[danielhollas]

Memory leak when using the @disable macro

[tclune]

OK - I think I have at least a glimmer as to what is going on now, but I think it is the compiler that is likely at fault. I took a shortcut when introducing "test annotations" of which Disable is the main use. Each test is itself a dictionary of annotations. (My shortcut was to use inheritance (is-a) rather than composition (has-a).) But the dictionary itself uses allocatable components and should be deallocated when the test goes out of scope. For cases without Disable, the dictionary remains empty.

The problem with my theory is that there is no guarantee that another implementation would solve the problem, and none of the approaches I've contemplated are quite trivial. For my own notes, I'll list what I've thought of so far:

1. Add a clear() method to the Test class hierarchy and make sure that it is called in the driver. High probability of solving the memory leak, but rather a step in the wrong direction in terms of basic design.
2. Upgrade the dictionary to from my v1 implementation to v1. A useful thing on its own, but not very likely to change the results.
3. Switch things so that the Test class "has-a" dictionary of annotations. This would improve the design from a loose-coupling perspective, but probably has other design implications that I'm not immediately seeing.
4. Just realized a variant on (1) Just make the top most TestSuite object in the driver allocatable, and deallocate it at the end. Much easier than(1), does not really impact design. Might leave the internal dictionary as a leak, as I still think this is a compiler "bug".

I'll try to attempt (4) next weekend.

[tclune]

Apologies for the delay in following up. I took some downtime last weekend and jumped back in this weekend. Unfortunately there is something wrong with the gfortran configuration on my laptop, as I was unable to build pFUnit. (CI tests say all is good, so?) So went to build on our computing center cluster instead, and ... somehow I'm locked out.

Hopefully one or both of these issues are resolved quickly tomorrow morning and I can attempt some of the workarounds I mentioned previously.

[tclune]

OK - am now in an environment where I can reproduce the issue. Amusingly the first few things I tried actually made the leak slightly worse.

Switching to the newer implementation of my poor-man STL container analogs seems to have eliminated the leaks. But while I was at it, I went ahead and switched the treatment of annotations to "has-a" from "is-a". That was easier than I thought it would be, and is generally cleaner code.

Running CI for merge into develop branch now.

[tclune]

To be honest, I'm a bit (pleasantly) surprised that you are not seeing a modest leak for the non-disabled case. Been a while since I looked into the @disable logic, but will try to see if I can spot anything obvious.

[tclune]

Alas, my changes apparently break Intel in a way that I cannot readily find a workaround. Some sort of memory corruption so that it ends up with invalid pointers to individual tests, but some tests run through without issue.

I'm actually a bit surprised because I figured that a shallower inheritance chain would be less stressful for the compiler.

It also broke NAG in a somewhat surprising way, but there I was able to find a simple workaround.