Remove VecValid() from petsc-dev and your problem goes away Barry
On Nov 17, 2010, at 4:24 PM, Dmitry Karpeev wrote: > 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 >> >> >>
