---------- Forwarded message ---------- Date: Thu, 24 Mar 2011 09:51:54 -0400 From: Sebastian Steiger <[email protected]> To: [email protected], Matthew Knepley <[email protected]> Cc: Roy Stogner <[email protected]> Subject: Re: [petsc-maint #67637] Re: [petsc-users] Scalability of AO ?
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? 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 ------------------------------------------------------------------------------ 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
