[Octave-bug-tracker] [bug #50102] dlmread crashing the interpreter on Cygwin

[Dan Sebald]

Follow-up Comment #18, bug #50102 (project octave):

OK.  It does look like space is made for the whole matrix before the
assignments are made.

To point out my original theory about rmax going backward from 32, I printed
out the value of rmax and cmax whenever they change:


diff --git a/libinterp/corefcn/dlmread.cc b/libinterp/corefcn/dlmread.cc
--- a/libinterp/corefcn/dlmread.cc
+++ b/libinterp/corefcn/dlmread.cc
@@ -274,7 +274,9 @@ such as text, are also replaced by the @
   octave_idx_type c = 1;
   // Start with a reasonable size to avoid constant resizing of matrix.
   octave_idx_type rmax = 32;
+fprintf(stderr, "rnamx = %ld\n", rmax);
   octave_idx_type cmax = 0;
+fprintf(stderr, "cnamx = %ld\n", cmax);
 
   Matrix rdata (rmax, cmax, empty_value);
   ComplexMatrix cdata;
@@ -406,7 +408,9 @@ such as text, are also replaced by the @
               // Use resize_and_fill for the case of unequal length rows.
               // Keep rmax a power of 2.
               rmax = 2 * std::max (r-1, static_cast<octave_idx_type> (1));
+fprintf(stderr, "rmax = %ld\n", rmax);
               cmax = std::max (c, cmax);
+fprintf(stderr, "cmax = %ld\n", cmax);
               if (iscmplx)
                 cdata.resize (rmax, cmax, empty_value);
               else


Here's the result for a simple 2 by 3 matrix:


octave:2> x = dlmread('mat2x3.csv')
rmax = 32
cmax = 0
rmax = 2
cmax = 3
x =

   1   2   3
   4   5   6


Again, not a bug, but it defeats the purpose of setting rmax to 32, which the
comment says is to prevent those first bunch of resizes that happen so quickly
as the matrix starts out.  In my opinion, I wouldn't be too worried if rmax
started at 2 (initializing rmax = 0 will result in


    rmax = 2 * std::max (r-1, static_cast<octave_idx_type> (1));


rmax equal 2.  Those very first re-assignments, although coming quickly, are
very small and don't consume much CPU.  It's the bigger resizing that might
have to expand the matrix and copy a large hunk of memory.

I did find an inconsistency in behavior when choosing the starting indeces too
large to have valid data.  If the row is too large, the result is empty
matrix; if the column is too big, the result is an error:


octave:10> x = dlmread('mat2x3.csv',',',10,1)
x = [](32x0)
octave:11> x = dlmread('mat2x3.csv',',',1,10)
error: index (_,11): but object has size 2x3



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?50102>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/