bugGNU Octave - Bugs: bug #37891, Segfault in __contourc__ when Java...

 
 

bug #37891: Segfault in __contourc__ when Java runtime is loaded

Submitted by:  Mike Miller <mtmiller>
Submitted on:  Sun 09 Dec 2012 07:48:54 PM UTC  
 
Category: LibrariesSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Segfault, Bus Error, etc.
Status: FixedAssigned to: None
Originator Name: Open/Closed: Closed
Release: devOperating System: GNU/Linux

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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.

Rik <rik5>
Project Administrator
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)

Mike Miller <mtmiller>
Project Administrator
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.

Rik <rik5>
Project Administrator
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.

Mike Miller <mtmiller>
Project Administrator
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.

Rik <rik5>
Project Administrator
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

Jordi GutiƩrrez Hermoso <jordigh>
Project Administrator
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.

Mike Miller <mtmiller>
Project Administrator
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.

Rik <rik5>
Project Administrator
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.

Mike Miller <mtmiller>
Project Administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #27182:  spiral.png added by mtmiller (177KiB - image/png)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by mtmiller (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 5 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun 03 Feb 2013 05:39:52 AM UTCmtmillerDependencies-=>bugs #38237 is dependent
    Tue 01 Jan 2013 08:22:38 PM UTCmtmillerAttached File-=>Added spiral.png, #27182
      StatusConfirmed=>Fixed
      Open/ClosedOpen=>Closed
    Mon 10 Dec 2012 11:21:28 PM UTCrik5StatusNone=>Confirmed

    Back to the top


    Powered by Savane 3.1-cleanup1