octave-bug-tracker
[Top][All Lists]
Advanced

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

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


From: Dan Sebald
Subject: [Octave-bug-tracker] [bug #50102] dlmread crashing the interpreter on Cygwin
Date: Mon, 13 Mar 2017 12:32:09 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0

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

No hurry Rik, but I'd prefer you fix this one whenever you find the time.

There is something dodgy here, and I think that the following conditional
might be too broad:



  // Start with a reasonable size to avoid constant resizing of matrix.
  octave_idx_type rmax = 32;
  octave_idx_type cmax = 0;
[snip]
          c = (c > j + 1 ? c : j + 1);
          if (r > rmax || c > cmax)
            {
              // 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));
              cmax = std::max (c, cmax);
              if (iscmplx)
                cdata.resize (rmax, cmax, empty_value);
              else
                rdata.resize (rmax, cmax, empty_value);
            }


On the first pass, c > cmax will test true.  So, right away, since r=1, rmax =
2 * max(0,1) = 2 such that rmax goes from 32 down to 2.

That in itself isn't a bug, as rmax will just keep incrementing again.  But I
keep wondering if there is a scenario where if r = 2, then

rmax = max(r-1, 1)
= max(2-1,1)
= 2

I.e., the buffer doesn't expand when it is expected to.  So, I wonder if
perhaps the single "if (r > rmax || c > cmax)" should be broken in "if (r >
rmax)" and "if (c > cmax)" where in the first case the row size is readjusted
and in the second case the column size is adjusted (and r > rmax test can be
moved earlier).

Also, why not simply use the doubling-buffer-size rule for columns as well as
rows?  The user could mistakenly, or otherwise, input a long data file for
which there are only white space separators as opposed to new-line separators.
 The former would be much slower than the latter.

    _______________________________________________________

Reply to this item at:

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

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




reply via email to

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