Unexpected behaviour after using SolverInterface destructor

[Dominanz]

I have experienced a problem when allocating a SolverInterface object dynamically. The following lines of code reproduce my observation (at least on my machine):

SolverInterface* interface;
interface = new SolverInterface("SolverOne",0,1);
interface->configure("precice-config.xml");
delete interface;
interface = new SolverInterface("SolverOne",0,1);
interface->configure("precice-config.xml");

When doing this together with the config from the solverdummies, preCICE throws the following error:
Participant "SolverTwo" can read/write data "Velocities" only once!

I suspect that this behaviour is unintended. I would expect that, after destroying the old SolverInterface and deallocating its memory, I can allocate a new instance of SolverInterface and configure it again.
Searching the code of preCICE, I found that the error is thrown here. My guess would be that the destructor of the SolverInterface class doesn't work properly. It seems that the second SolverInterface created in the example code above encounters remnants of the previous one, causing it to throw the error.

This problem is probably very uncommon, since SolverInterfaces are allocated statically in most examples I have seen, so they are only destructed once the program exits anyway.
However, I encountered this problem while working on MATLAB bindings, where working with pointers is not really evitable. Since exiting MATLAB means ending the session, I encounter the problem whenever I try to run a program coupled with preCICE repeatedly in the same MATLAB session, which is very annoying (especially for testing and debugging). Therefore, I'd really appreciate a fix or a suggestion on how to prevent this error.

Thanks for any help!

[uekerman]

This is a known bug due to some static IDs preCICE uses. I have a workaround patch (but no proper solution) on my laptop, which I don't have with me. I can post my patch on Monday.

[Dominanz]

This would be welcome! Could you maybe give a few more details on where the problem originates? Maybe I find the time to have a look on that.

[BenjaminRodenberg]

As far as I understand the situation, here is the proposed workaround: 873a99f

However, this is not a proper solution and therefore, we do not want to merge it into develop and we cannot close this issue. @uekerman is this correct?

[uekerman]

All yes.
The proper solution will be #385
Let's keep this open till we solved it in develop.

[fsimonis]

Reconstruction is possible after #1419