[Octave-bug-tracker] [bug #53514] Memory leaks in 4.4 release

[Rik]

Follow-up Comment #8, bug #53514 (project octave):

I'm getting a heap-buffer-overflow in __expint__.cc when running the tests for
cosint.m.  Adding Michele Ginesi to the CC list for this bug since he wrote
that code.  The abbreviated backtrace from gdb is:


================================================
==18426==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x602000a952f0 at pc 0x7f0cbc05fef3 bp 0x7f0c960780d0 sp 0x7f0c960780c0
READ of size 16 at 0x602000a952f0 thread T3 (QThread)
    #0 0x7f0cbc05fef2 in F__expint__(octave_value_list const&, int)
libinterp/corefcn/__expint__.cc:134
    #1 0x7f0cbbcf6740 in octave_builtin::call(octave::tree_evaluator&, int,
octave_value_list const&) libinterp/octave-value/ov-builtin.cc:65
    #2 0x7f0cbc00996c in
octave::tree_evaluator::visit_index_expression(octave::tree_index_expression&)
libinterp/parse-tree/pt-eval.cc:1335
    #3 0x7f0cbc03cd36 in
octave::tree_index_expression::accept(octave::tree_walker&)
libinterp/parse-tree/pt-idx.h:102
    #4 0x7f0cbbd78fb7 in
octave::tree_evaluator::evaluate(octave::tree_expression*, int)
libinterp/parse-tree/pt-eval.h:300


Looking at the code around line 134 in __expint__.cc I see this:


      // Initialize output and inputs
      ComplexColumnVector output (output_dv);
      ComplexNDArray x;

      if (numel_x == 1)
        x = ComplexNDArray (output_dv, args(0).complex_value ());
      else
        x = args(0).complex_array_value ();

      // Initialize variables used in algorithm
      static const Complex tiny = pow (2, -100);
      static const double eps = std::numeric_limits<double>::epsilon ();
      Complex cone (1.0, 0.0);
      Complex czero (0.0, 0.0);
-->   Complex xj = x(0);
      Complex y = tiny;
      Complex Cj = y;
      Complex Dj = czero;
      Complex alpha_j = cone;
      Complex beta_j = xj;
      Complex Deltaj = czero;



My guess is that the code is not properly handling the case where the matrix
is empty, i.e., numel == 0.  In that case, we shouldn't be indexing in to the
array to get x(0).

The loop below it is


      // Loop over all scenarios
      for (octave_idx_type i = 0; i < numel_x; ++i)
        {
          // Catch Ctrl+C
          OCTAVE_QUIT;

          // Variable initialization for the current element
          xj = x(i);
          y = tiny;
          Cj = y;
          Dj = czero;
          alpha_j = cone;
          beta_j = xj;
          Deltaj = czero;
          j = 1;


Given that the first thing the body of the loop does is to initialize all of
these values, it might be better to eliminate the initialization outside the
loop.



    _______________________________________________________

Reply to this item at:

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

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