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 05:27:20 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:51.0) Gecko/20100101 Firefox/51.0

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

I'm going to add to the noise here because I have an obscure bug I can't make
sense of and the only info is dlmread and munmap_chunk().  (This is linux,
latest development code.)

I can't narrow things down because it happens under a rather complex script
involving lots of data files and links.  If I try to replicate things with
direct code on a specific file, the crash doesn't happen.

So, I'll just give the message before crash and see if it rings a bell for
anyone:


warning: dlmread: '/home/sebald/data/foo.csv' found by searching load path
*** Error in `/usr/local/src/octave/octave/build3/src/.libs/lt-octave-gui':
munmap_chunk(): invalid pointer: 0x00007f23549c2e78 ***
Aborted


Launched with:

/usr/local/src/octave/octave/build3/run-octave --no-gui

Why the error is in the gui library when launched with --no-gui, I don't know.
 Maybe the bad pointer is somewhere else.  And what this munmap_chunk() is, I
have no idea.  Must be a system library used either by Octave core or Qt.

The program crashes at a line that does csvread() which must call dlmread(). 
Also, this line of code is within a try-end block.

I have an older Octave version installed system wide and run via octave-cli
that works fine.

The most recent dlmread-related changeset is

http://hg.savannah.gnu.org/hgweb/octave/rev/68d5c4759783

Rik, you know this better than I, as I'm just looking at the changeset.  If I
were to investigate deeper, I'd probably start with checking this:


-              cmax++;
+              // Separator followed by EOL doesn't generate extra column
+              if (pos2 != std::string::npos)
+                cmax++;


or, more likely, this


-              rmax = 2*r;
-              cmax = c;
+              rmax = 2 * std::max (r-1, 1);  // keep rmax a power of 2
+              cmax = std::max (c, cmax);

Why was the change made from 2*r to 2*(r-1)?  Was there an extra row because
dlmread attempts to read into a "next" line not knowing if there would be one
or not?

Dan


    _______________________________________________________

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]