[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.
jwe
- Re: moving toward a 3.0 release, (continued)
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release, David Bateman, 2006/09/27
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/28
- Re: moving toward a 3.0 release, David Bateman, 2006/09/28
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/28
- Re: moving toward a 3.0 release, Joe Koski, 2006/09/28
- Re: moving toward a 3.0 release, Sebastien Loisel, 2006/09/28
- Re: moving toward a 3.0 release, David Bateman, 2006/09/29
- Re: moving toward a 3.0 release, Joe Koski, 2006/09/29
- arpack/eigs problems (was: Re: moving toward a 3.0 release), John W. Eaton, 2006/09/29
- Re: moving toward a 3.0 release,
John W. Eaton <=
- Re: moving toward a 3.0 release, David Bateman, 2006/09/27
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release, David Bateman, 2006/09/27
- Re: moving toward a 3.0 release, Søren Hauberg, 2006/09/27
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release, Quentin Spencer, 2006/09/27
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/27
- Re: moving toward a 3.0 release, Sebastien Loisel, 2006/09/27
- Re: moving toward a 3.0 release, David Grohmann, 2006/09/28
- Re: moving toward a 3.0 release, John W. Eaton, 2006/09/28