---------- Forwarded message ----------
Date: Thu, 24 Mar 2011 08:53:13 -0500
From: Matthew Knepley <knepley@...>
To: Sebastian Steiger <steiger@...>,
Cc: Roy Stogner <roystgnr@...>
Subject: Re: [petsc-maint #67637] Re: [petsc-users] Scalability of AO ?
On Thu, Mar 24, 2011 at 8:51 AM, Sebastian Steiger <steiger@...> wrote:
> > ==14358== Invalid write of size 8
> > ==14358== at 0xAE305B2: SNESLineSearchSetParams(_p_SNES*,
> > double, double) (lsparams.c:42)
> > ==14358== by 0x50216E4:
> > NonlinearPoisson::set_numerical_solver_options()
> > (NonlinearPoisson.cpp:998)
> > This does not appear to have to do with the last argument. For line
> > lsparams.c:42 of petsc-dev I have
> > if (maxstep >= 0.0) ls->maxstep = maxstep;
> This is fairly simple to look at with gdb. What does the ls struct look
After I recompiled PETSc with -O0 I see the following in gdb:
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff0b4b5d0 in SNESLineSearchSetParams (snes=0xb0f100, alpha=-2,
maxstep=8.875, minlambda=-2) at lsparams.c:42
42 if (maxstep >= 0.0) ls->maxstep = maxstep;
(gdb) print snes
$1 = (SNES) 0xb0f100
(gdb) print ls
$2 = (SNES_LS *) 0x0
#0 0x00007ffff0b4b5d0 in SNESLineSearchSetParams (snes=0xb0f100,
alpha=-2, maxstep=8.875, minlambda=-2) at lsparams.c:42
#1 0x00007ffff78a96e5 in NonlinearPoisson::set_numerical_solver_options
(this=0xa18890) at NonlinearPoisson.cpp:998
So it looks like ls is NULL. When I browse through our code I see that
we're getting the SNES object from libmesh and we're not calling
SNESSetType() explicitly on our side. Might there be a change in default
Its not a change in default behavior, but could easily be a an unintended side
effect. For instance, if SNESSetFromOptions() was originally being called, it
would set a default type. However, if that and SNESSetType() is missing, we
trust the user that they do not want the type set.
Maybe you could introduce a small assert that ls!=NULL...
> > 1) My application is used by grad students who do not know
> much about compiling, HPC etc.
> > I think this is orthogonal since we are not talking about users
> building the code, only maintainers that build the code in either case.
> Well, our students do build the code because they contribute some small
> parts, but their knowledge is limited to typing 'make'.
> Exactly. That should work the same.
... except that we also have SLEPc and libmesh to build which depend on
PETSc. I had to bother Jose Roman and Roy Stogner to get their
dev-versions working with petsc-dev. All in all it's just a painful
process that we'd only like to go through once a year or so.
What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments
-- Norbert Wiener