Wed 02 Jan 2013 06:20:57 PM UTC, comment #8:
This is the second bug which was provoked by Java, but turned out to be a problem with core Octave. Thanks for clarifying and fixing this.
|
Tue 01 Jan 2013 08:22:38 PM UTC, comment #7:
Fixed by converting the drawcn function to iterative instead of recursive:
http://hg.savannah.gnu.org/hgweb/octave/rev/704e15f8fecd
JFTR I was indeed able to reproduce this without loading Java, it just took a much bigger example. The attached image caused contour to crash for me the same way without my fix, running
(file #27182)
|
Wed 19 Dec 2012 06:29:39 PM UTC, comment #6:
I just fixed another segfault that turned out to be Octave's problem, provoked merely by the different memory arrangement of having Java loaded. Unfortunately, this segfault is still there.
The code works when I compile with '-O0', but not with '-O2' or '-O1'. This could be just issues in the way that gcc is placing things in memory. Or it could be a bug with the compiler which is somehow doing too much or the wrong type of optimization. My version is gcc-4.4.3. Testing with other compilers, and whether '-O0' works, would be useful.
|
Wed 12 Dec 2012 12:27:05 AM UTC, comment #5:
This doesn't look like a case of infinite recursion, it looks repeatable and finite from my testing, but this dataset does push it pretty hard. I think maybe loading the JRE sucks up a lot of stack space that the _contourc_ algorithm needs.
The little I've looked at the algorithm so far, it looks like it's using recursion to trace each distinct contour line in the x-y plane, so the more points connected with a single contour line the greater the recursion will be.
I added a stack depth counter to see how deep it's going and compare with and without Java. Without the JRE loaded, the drawcn function recurses to a maximum depth of 3946 and still returns and completes successfully, draws a reasonable looking contour.
With Java in the mix, the segfault occurs at a depth of 3135 drawcn calls. The arguments to drawcn all look the same as in the working case without Java loaded.
It looks like drawcn was written to take advantage of tail recursion but gcc doesn't seem to be doing it.
|
Tue 11 Dec 2012 04:38:40 PM UTC, comment #4:
Yes, the backtrace is around 2500 frames deep. I tried increasing the stacksize of the shell process running Octave but I still get segfaults.
The problem is in _contour_.cc. I think the issue has been there all along, but the Java interaction has exposed it. I get the segfault in drawcn which, if you look at the bottom of the function, will see is recursive and calls itself. This is how the frame stacks are building up.
The bottom of drawcn which stops the recursion is shown below, but it is still something of a mystery. If I put printf statements on some of the variables I end up segfaulting in the printf routine.
|
Tue 11 Dec 2012 02:05:22 PM UTC, comment #3:
> I see a gdb backtrace thousands of frames deep when I get the segfault with -O2,
Obviously an infinite recursion, c.f. bug #37750
|
Tue 11 Dec 2012 03:54:06 AM UTC, comment #2:
I haven't tried with -O0 yet, I'll check that out and try some other options as well. I see a gdb backtrace thousands of frames deep when I get the segfault with -O2, do you get the same?
We can rule out urlwrite, that is not needed to make it crash, I just threw that in there to make it easier to download the data file from the Debian BTS in the same script.
|
Mon 10 Dec 2012 11:21:28 PM UTC, comment #1:
This is going to be tougher to debug than I thought. When I compile with a standard -O2 I see the segfault. When I compile with '-g -O0' to get good debug information I know longer get the segfault. So yes, it does appear that someone is overrunning a memory boundary and that even small tweaks can change the memory segment alignment and prevent the segfault. Even though it was discovered with Java it is not clear that it is Java, urlwrite, or contourc which is at fault.
|
Sun 09 Dec 2012 07:48:54 PM UTC, original submission:
With the Java runtime loaded, a segfault occurs when running a certain dataset through contourc.
If the Java runtime is not loaded, it does not crash. If a different contour level value is given, it does not crash.
Originally reported at http://bugs.debian.org/695434.
|