[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: moving toward a 3.0 release

From: John W. Eaton
Subject: Re: moving toward a 3.0 release
Date: Wed, 27 Sep 2006 18:55:36 -0400

On 28-Sep-2006, David Bateman wrote:

| > Are all the arrays (not just the work arrays) that are passed to
| > dneupd the correct size? 
| Not only are they the correct size they are larger than recommended.
| Valgrind is still pointing to dneupd writing beyond the end of
| particular the variable v, dr, and di not matter how big I make them.
| Note eig_val isn't even passed to arpack!
| > Are you sure they are not corrupted in some
| > way even before the call to dneupd?  It is possible that there is a
| > buffer overwriting problem that happens even before that call.
| The first relevant (there is also a conditional branch on uninitialized
| value in libc vnprintf code when called from Ffprintf) is
| ==11854==
| ==11854== Invalid write of size 8
| ==11854==    at 0x1D52F244: (within /usr/lib/atlas/P4SSE2/libblas.so.3.0)
| ==11854==  Address 0x1F748060 is 0 bytes after a block of size 56 alloc'd
| ==11854==    at 0x1B900070: operator new[](unsigned)
| (vg_replace_malloc.c:197)
| ==11854==    by 0x1F97C5F5: Feigs(octave_value_list const&, int)
| (eigs.cc:1276)
| Note that 1276 for me is a different line than in the eigs I sent as I
| modified the code to use new/delete.. In any case this line is
|                     double *dr = new double [k + 3];
| for me. However I saw exactly the same issue with
|                     OCTAVE_LOCAL_BUFFER (double, dr, k + 3);
| Note that the dneupd.f file suggests that dr should be "k+1" in size.
| However if I make it that small the crash happens at about the 4th
| iteration rather than the 10000-th.

It looks like the arrays in dneupd are declared like this:

      integer    iparam(11), ipntr(14)
      logical    select(ncv)
      Double precision 
     &           dr(nev+1)    , di(nev+1), resid(n)  , 
     &           v(ldv,ncv)   , z(ldz,*) , workd(3*n), 
     &           workl(lworkl), workev(3*ncv)

so maybe it would help to compile this with bounds checking enabled
(for g77, it is -ffortran-bounds-check)?  That should point out where
dneupd is overrunning an array.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]