[petsc-users] many valgrind error of petsc string functions

[Barry Smith]

   You could try building everything with the gnu compilers and see if these message all go away; I bet they will because they are caused by problems with the intel compilers.

   Barry

On Dec 4, 2011, at 12:29 AM, Gong Ding wrote:

> I spend hours on checking the valgrind reporting but find nothing.
> Change PetscMalloc to malloc in PetscStrallocpy can reduce memory warning about mem alignment, but not critical.
> Sigh...
> 
> PetscErrorCode  PetscStrallocpy(const char s[],char *t[])
> {
>   PetscErrorCode ierr;
>   size_t         len=0;
>   char           *tmp = 0;
> 
>   PetscFunctionBegin;
>   if (s) {
>     ierr = PetscStrlen(s,&len);CHKERRQ(ierr);
>     tmp = (char *)malloc((1+len)*sizeof(char));
>     ierr = PetscStrcpy(tmp,s);CHKERRQ(ierr);
>     tmp[len] = 0;
>   }
>   *t = tmp;
>   PetscFunctionReturn(0);
> } 
> 
> The most dangerous error may be caused by intel library, not petsc.
> Anyway, you can put it away.
> 
> ==5545== Invalid read of size 8
> ==5545==    at 0x57A9568: __intel_sse2_strlen (in /opt/intel/Compiler/11.1/038/lib/intel64/libirc.so)
> ==5545==    by 0x171AB46: PetscStrlen (str.c:149)
> ==5545==    by 0x171B3B8: PetscStrallocpy (str.c:185)
> ==5545==    by 0x16CAD2C: PetscFListGetPathAndFunction (reg.c:25)
> ==5545==    by 0x16CA59A: PetscFListAdd (reg.c:229)
> ==5545==    by 0x16C9F61: PetscFListDuplicate (reg.c:596)
> ==5545==    by 0x1890951: MatDuplicateNoCreate_SeqAIJ (aij.c:3964)
> ==5545==    by 0x18BBB77: MatILUFactorSymbolic_SeqAIJ_ilu0 (aijfact.c:1639)
> ==5545==    by 0x18B9F6B: MatILUFactorSymbolic_SeqAIJ (aijfact.c:1740)
> ==5545==    by 0x185315A: MatILUFactorSymbolic (matrix.c:6092)
> ==5545==    by 0x1C9CD28: PCSetUp_ILU (ilu.c:216)
> ==5545==    by 0x1F5B32B: PCSetUp (precon.c:819)
> ==5545==  Address 0x8416118 is 24 bytes inside a block of size 28 alloc'd
> ==5545==    at 0x4A0776F: malloc (vg_replace_malloc.c:263)
> ==5545==    by 0x171B3CD: PetscStrallocpy (str.c:186)
> ==5545==    by 0x16CAD2C: PetscFListGetPathAndFunction (reg.c:25)
> ==5545==    by 0x16CA8D2: PetscFListAdd (reg.c:205)
> ==5545==    by 0x16E4014: PetscObjectComposeFunction_Petsc (inherit.c:466)
> ==5545==    by 0x16E5214: PetscObjectComposeFunction (inherit.c:600)
> ==5545==    by 0x18A0BBA: MatCreate_SeqAIJ (aij.c:3814)
> ==5545==    by 0x1871689: MatSetType (matreg.c:73)
> ==5545==    by 0x1247AF0: FVM_NonlinearSolver::setup_nonlinear_data() (fvm_nonlinear_solver.cc:220)
> ==5545==    by 0x132CCAE: PoissonSolver::create_solver() (poisson.cc:51)
> ==5545==    by 0xEC7A61: SolverControl::do_solve(Parser::Card const&) (control.cc:1081)
> ==5545==    by 0xEB9688: SolverControl::mainloop() (control.cc:200)
> 
> 
> 
> 
> On Sat, Dec 3, 2011 at 06:18, Gong Ding <gdiso at ustc.edu> wrote:
> In the function of PetscOptionsFindPair_Private (options.c line 1098), there are still some code with the same problem.
> 
> Are you passing a full path to the option? Or just many very long prefixes?
> 
> This absolutely needs to be fixed, but I think there are a lot of places where fixed-length temporary buffers are used for building options keys and values. I would like to know how you are triggering these overflows so that I can stand a decent chance of getting all of them.