On Sun, Feb 3, 2013 at 11:09 AM, Matthew Knepley <knepley at gmail.com> wrote:
> If the checkin you originally complained about the build did not fail and > a memory leak did not appear. You > still cannot explain what was wrong there, so you proceed to a different > problem. > Users even write petsc-maint about the warnings. You did not address that point. Pushing as a checkpointing mechanism discourages review. > > >> Since we make API changes in petsc-dev, people may need to update their >> code. For example, I updated parmod last night and had to update a few >> things for it to build, but then -malloc_dump told me about a memory leak. >> If I was not a PETSc developer, should I have expected it to be due to a >> bug in my code or a new bug in PETSc? As it turns out, you introduced the >> memory leak as part of a bunch of other stuff >> > > Yes, a memory leak did appear here. However, it appeared in a complete > checkin that had a test to go with it, > Either that test did not actually run the code, or you didn't have -malloc_dump in the test. (It should _always_ be used when testing.) > exactly as you ask. We see that even that is insufficient sometimes to > discover a minor bug like this. So your > second example is really about the shortcomings of the strategy you > propose. > Your patch did several things. It would have been easier to spot (though not necessarily noticed) if the patch had been split apart. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20130203/d97234f2/attachment.html>
