<div>I spend hours on checking the valgrind reporting but find nothing.<br>Change PetscMalloc to malloc in PetscStrallocpy can reduce memory warning about mem alignment, but not critical.<br>Sigh...<br><br>PetscErrorCode PetscStrallocpy(const char s[],char *t[])<br>{<br> PetscErrorCode ierr;<br> size_t len=0;<br> char *tmp = 0;<br><br> PetscFunctionBegin;<br> if (s) {<br> ierr = PetscStrlen(s,&len);CHKERRQ(ierr);<br> tmp = (char *)malloc((1+len)*sizeof(char));<br> ierr = PetscStrcpy(tmp,s);CHKERRQ(ierr);<br> tmp[len] = 0;<br> }<br> *t = tmp;<br> PetscFunctionReturn(0);<br>} <br><br>The most dangerous error may be caused by intel library, not petsc.<br>Anyway, you can put it away.<br><br>==5545== Invalid read of size 8<br>==5545== at 0x57A9568: __intel_sse2_strlen (in /opt/intel/Compiler/11.1/038/lib/intel64/libirc.so)<br>==5545== by 0x171AB46: PetscStrlen (str.c:149)<br>==5545== by 0x171B3B8: PetscStrallocpy (str.c:185)<br>==5545== by 0x16CAD2C: PetscFListGetPathAndFunction (reg.c:25)<br>==5545== by 0x16CA59A: PetscFListAdd (reg.c:229)<br>==5545== by 0x16C9F61: PetscFListDuplicate (reg.c:596)<br>==5545== by 0x1890951: MatDuplicateNoCreate_SeqAIJ (aij.c:3964)<br>==5545== by 0x18BBB77: MatILUFactorSymbolic_SeqAIJ_ilu0 (aijfact.c:1639)<br>==5545== by 0x18B9F6B: MatILUFactorSymbolic_SeqAIJ (aijfact.c:1740)<br>==5545== by 0x185315A: MatILUFactorSymbolic (matrix.c:6092)<br>==5545== by 0x1C9CD28: PCSetUp_ILU (ilu.c:216)<br>==5545== by 0x1F5B32B: PCSetUp (precon.c:819)<br>==5545== Address 0x8416118 is 24 bytes inside a block of size 28 alloc'd<br>==5545== at 0x4A0776F: malloc (vg_replace_malloc.c:263)<br>==5545== by 0x171B3CD: PetscStrallocpy (str.c:186)<br>==5545== by 0x16CAD2C: PetscFListGetPathAndFunction (reg.c:25)<br>==5545== by 0x16CA8D2: PetscFListAdd (reg.c:205)<br>==5545== by 0x16E4014: PetscObjectComposeFunction_Petsc (inherit.c:466)<br>==5545== by 0x16E5214: PetscObjectComposeFunction (inherit.c:600)<br>==5545== by 0x18A0BBA: MatCreate_SeqAIJ (aij.c:3814)<br>==5545== by 0x1871689: MatSetType (matreg.c:73)<br>==5545== by 0x1247AF0: FVM_NonlinearSolver::setup_nonlinear_data() (fvm_nonlinear_solver.cc:220)<br>==5545== by 0x132CCAE: PoissonSolver::create_solver() (poisson.cc:51)<br>==5545== by 0xEC7A61: SolverControl::do_solve(Parser::Card const&) (control.cc:1081)<br>==5545== by 0xEB9688: SolverControl::mainloop() (control.cc:200)<br><br><br><br></div><blockquote style="padding-left:5px;margin-left:5px;border-left:#a0c6e5 2px solid;margin-right:0px"><br><div class="gmail_quote">On Sat, Dec 3, 2011 at 06:18, Gong Ding <span dir="ltr"><<a href="mailto:gdiso@ustc.edu">gdiso@ustc.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
In the function of PetscOptionsFindPair_Private (options.c line 1098), there are still some code with the same problem.</blockquote></div><br><div>Are you passing a full path to the option? Or just many very long prefixes?</div>
<div><br></div><div>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.</div>
</blockquote><span ></span>