---------- Forwarded message ----------
Date: Thu, 24 Mar 2011 08:53:13 -0500
From: Matthew Knepley <[email protected]>
To: Sebastian Steiger <[email protected]>,
petsc-maint <[email protected]>
Cc: Roy Stogner <[email protected]>
Subject: Re: [petsc-maint #67637] Re: [petsc-users] Scalability of AO ?
On Thu, Mar 24, 2011 at 8:51 AM, Sebastian Steiger <[email protected]> wrote:
Matt,
> > ==14358== Invalid write of size 8
> > ==14358== at 0xAE305B2: SNESLineSearchSetParams(_p_SNES*,
> double,
> > 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
> like?
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
(gdb) where
#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
behavior?
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.
Matt
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.
Sebastian
--
What most experimenters take for granted before they begin their experiments is
infinitely more interesting than any results to which their experiments
lead.
-- Norbert Wiener
------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software
be a part of the solution? Download the Intel(R) Manageability Checker
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Libmesh-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-devel
