I agree that my changes should have nothing to do with VecValid, which is why this is so baffling. I've rebuilt the fortran bindings, rebuilt PETSc etc, etc -- to no avail. I thought it might be a memory corruption due to an expanded IS struct, but valgrind doesn't detect anything. This error is the reason I've been sitting on this commit for a while, but I figured someone else might figure it out faster than I can :-) Dmitry.
On Wed, Nov 17, 2010 at 4:19 PM, Barry Smith <bsmith at mcs.anl.gov> wrote: > > On Nov 17, 2010, at 4:15 PM, Dmitry Karpeev wrote: > >> I just pushed an IS update that causes problems in some fortran tests. >> I'm not sure exactly what's going on, but a failure occurs, for >> example, in src/vec/examples/tests/ex1f >> in VecValid. ?Looked at with a debugger it reveals that 'flg', a >> pointer to boolean that is being passed from Fortran >> to C, is wiped out and emerges as NULL on the C side (I assume, upon a >> cast; since there is no temporary >> in vecvalid_ that holds the result of the "cast", I can't really >> examine the intermediate value passed to C). >> >> I've been trying to figure this out for a bit, but have come up with >> nothing so far (e.g., valgrind runs on ex1f fine). >> I'm sure this will show up in the nightly builds, but I figured I'd >> push this change, hoping that someone with a >> better knowledge of Fortran bindings will help me figure this out. >> >> Thanks. >> Dmitry. > > ?Huh, your changes shouldn't have anything to do with VecValid, nor affect it > in any way. Any problem should exist both with or without your changes > > ? BTW: VecValid() is not a legitimate function, should never be used and > should be removed from PETSc-dev ASAP. Why it is too dangerous poking around > with an unknown pointer. > > ? Barry > > >
