On Thu, Oct 03, 2013 at 08:52:50AM +0000, rhaas@tapir.caltech.edu wrote:
initialize all unused memory to zero before output
Hi,
If this is done by Pugh, doesn't this mask real usage of uninitialized memory, such that tools like valgrind cannot find potential problems? Wouldn't it better not to output uninitialized values, or initialize them in the user thorns, not in the driver?
Frank
Hello all,
If this is done by Pugh, doesn't this mask real usage of uninitialized memory, such that tools like valgrind cannot find potential problems?
Yes, it will do that, unfortunately. The only way around that would be to either modify the test so that all sphericalsurfaces used have the same nphi and ntheta, or to modify AHFinderDirect to initialize all spherical surfaces (up to maxnphi and maxntheta) with known values so that any garbage is wipe. This would mask only errors in AHFinderDirect.
This is not really different from what happens in Carpet if you turn on poisoning and since it is used only for this test (via a parameter choice) I do not really see it as an issue right now.
Wouldn't it better not to output uninitialized values, or initialize them in the user thorns, not in the driver?
Not outputting them is impossible since sf_radius is a vector of 2d grid arrays and all grid arrays in the vector need to have the same size. Initializing in the thorn would be possible and would mean that valgrind works (which is certainly something I would not want to lose). Initializing in the thorn would still mask errors when the thorn itself then tries to itself access the freshly cleared values, so there would need to be a method to turn it off. One could think about only setting those parts that are not used for "real" data, which however makes for awkward code.
All in all, I would personally prefer the solution to only turn on poisoning when needed eg in production runs and non-valgrind where I want things to explode but to be able to turn it off so that valgrind can catch all access to non-initialized values,
Yours, Roland
users@lists.einsteintoolkit.org