Hi Doug,
Yes, sadly I have experienced the same but wasn’t able to allot the time to figure out if it was indeed a bug in Sacado (and maybe something that’s already been fixed upstream in a newer version of Trilinos than I was using) or something that we did. I’m really glad that you managed to supply them with a MWE that definitely reproduces the issue, since this disambiguates their code from our drivers. Thank you for that. For your interest, I’ve attached the MWE that I made at the time. I can only suppose that back then I wasn’t confident that I’d recreated the conditions for the leak, because the valgrind logs that I still have didn’t report and memory as being “definitely lost”. I guess the trick would have been to have stuck all of this in a loop, which I clearly didn’t think to do :-/
Since you’ve confirmed that you’ve experienced the same, I think that it would be worthwhile to add a note to this effect in our documentation. If you'd like to do so yourself, then free to make a suggestion where you think it would be appropriate to be. My first inclination would have been where the enumerated type sacado_rad_fad is documented, i.e.
but of course that’s completely up for discussion. Either way, I think that this should be documented because this issue may persist for some time, and it would be good to have a warning in place until we know which version of Trilinos has a fix in place. Perhaps we should also add a link there to your issue on their GitHub page so that the reader can easily find where to check the status of the issue?
I hope that you’ve spotted the sacado_fad_fad alternative that should work without issue. In many cases I would expect it to be less performant than the (buggy) Rad-Fad implementation but they both still have, at the very least, some use in debugging or prototyping.
Best,
Jean-Paul