bugGNU Octave - Bugs: bug #30044, x \ y causing coredump

 
 

bug #30044: x \ y causing coredump

Submitted by:  Muhali <muhali>
Submitted on:  Thu 03 Jun 2010 04:51:08 PM UTC  
 
Category: NoneSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Segfault, Bus Error, etc.
Status: FixedAssigned to: Jaroslav Hajek <highegg>
Originator Name: MuhaliOpen/Closed: Closed
Release: 3.2.4Operating 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)

Fri 09 Jul 2010 12:23:48 PM UTC, comment #9:

I've just discovered that the bug has already been reported (#0059) and LAPACK SVN now contains corrected formulas. Apparently both the docs and the automatic query are broken up to 3.2.1. So it seems we won't be able to switch to the auto queries any time soon :( At least in this case.

I updated (add87b12e63c) Octave to use the corrected formulas rather than my previous ad hoc adjustment. The bug is gone, which is a good omen.

Closing the bug. John, if you still want the testcase, mail me.

Jaroslav Hajek <highegg>In charge of this item.
Wed 23 Jun 2010 04:16:25 PM UTC, comment #8:

Could you please post the Fortran code for the test case?

John W. Eaton <jwe>
Project Administrator
Wed 16 Jun 2010 12:39:40 PM UTC, comment #7:

I've isolated the problem to a Fortran testcase. I'll submit a bug report to LAPACK when there's time. I have no proof for this, but adding 1 to NLVL in that calculation seems to be a sufficient workaround. I did it and marked as FIXME in the source code:
http://hg.savannah.gnu.org/hgweb/octave/rev/2786b7ae3f80

Jaroslav Hajek <highegg>In charge of this item.
Wed 16 Jun 2010 11:03:33 AM UTC, comment #6:

I can't reproduce this, but I'm not surprised, gdb occassionally gives me garbage, too. For instance, I now see

(gdb) p*retval.rep
Cannot access memory at address 0x0

I'd say that gdb is just confused.
I'll try to reproduce the error with stand-alone program, perhaps I'll be more lucky.

Jaroslav Hajek <highegg>In charge of this item.
Fri 11 Jun 2010 05:44:01 PM UTC, comment #5:

While trying to debug what is happening in ComplexMatrix::lssolve in the current development sources, I am seeing some strange things. For example, if I set a breakpoint at the first line in ComplexMatrix::lssolve where retval is declared and step just past this line, gdb tells me

(gdb) p *retval.rep
$35 = {
data = 0xa17400,
len = 119,
count = 0
}

I don't see how this can happen, and it looks like trouble for the count to be zero in an ArrayRep object.

Jaroslav, can you explain what is going on here?

John W. Eaton <jwe>
Project Administrator
Fri 11 Jun 2010 04:37:44 PM UTC, comment #4:

Oops, my previous program had a stupid error in it. I'm attaching a corrected version. However, this version appears to work correctly on my system, so now I'm not sure what the problem is. If it is a bug in Octave, then I would guess we are calling zgelsd incorrectly, but I'm not seeing the error yet...

(file #20736)

John W. Eaton <jwe>
Project Administrator
Thu 10 Jun 2010 05:01:07 PM UTC, comment #3:

I'm attaching a fortran program that also crashes on my system when compiled with

gfortran zgelsd-bug.f -llapack -lblas

(file #20729)

John W. Eaton <jwe>
Project Administrator
Fri 04 Jun 2010 08:35:57 AM UTC, comment #2:

The problem seems to be with RWORK size calculation for ZGELSD. I didn't, however, discover any difference between Octave's formula and the ZGELSD docs, suggesting that this may be a bug in LAPACK. I'll try to narrow it down to a stand-alone test case.

Jaroslav Hajek <highegg>In charge of this item.
Fri 04 Jun 2010 05:02:59 AM UTC, comment #1:

Confirmed on a development tip (10680:e00de2d5263c) on an x86_64 GNU/Linux system.

Rik <rik5>
Project Administrator
Thu 03 Jun 2010 04:51:08 PM UTC, original submission:

Here is how octave generates a coredump using Debian Etch, v. 3.2.4 (same happens for Ubuntu Jaunty, v. 3.0.1).

%> /usr/bin/octave -fq
octave:1> load foo.ob
octave:2> whos
Variables in the current scope:

Attr Name Size Bytes Class
==== ==== ==== ===== =====
ans 1x11 92 cell
x 119x119 226576 double
y 119x119 226576 double

Total is 28333 elements using 453244 bytes

octave:3> x \ y ;
warning: matrix singular to machine precision, rcond = 3.61519e-19
warning: attempting to find minimum norm solution
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Segmentation fault

Muhali <muhali>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #20737:  zgelsd-bug.f added by jwe (617B - text/x-fortran)
file #20684:  foo.ob.bz2 added by muhali (160KiB - application/x-bzip - foo.ob.bz2)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jwe (Updated the item)
  • -unavailable- added by highegg (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by muhali (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 22 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 09 Jul 2010 12:23:48 PM UTChigheggStatusPostponed=>Fixed
      Open/ClosedOpen=>Closed
      Summaryx \\ y causing coredump=>x \ y causing coredump
    Wed 23 Jun 2010 04:16:25 PM UTCjweSummaryx \\ y causing coredump=>x \ y causing coredump
    Wed 16 Jun 2010 12:39:40 PM UTChigheggStatusConfirmed=>Postponed
      Assigned toNone=>highegg
      Summaryx \\ y causing coredump=>x \ y causing coredump
    Wed 16 Jun 2010 11:03:33 AM UTChigheggSummaryx \\ y causing coredump=>x \ y causing coredump
    Fri 11 Jun 2010 05:44:01 PM UTCjweSummaryx \\ y causing coredump=>x \ y causing coredump
    Fri 11 Jun 2010 04:41:07 PM UTCjweAttached File#20736=>Removed
    Fri 11 Jun 2010 04:40:55 PM UTCjweAttached File-=>Added zgelsd-bug.f, #20737
      Summaryx \\ y causing coredump=>x \ y causing coredump
    Fri 11 Jun 2010 04:39:26 PM UTCjweAttached File#20729=>Removed
    Fri 11 Jun 2010 04:37:44 PM UTCjweAttached File-=>Added zgelsd-bug.f, #20736
      Summaryx \\ y causing coredump=>x \ y causing coredump
    Thu 10 Jun 2010 05:01:07 PM UTCjweAttached File-=>Added zgelsd-bug.f, #20729
      Summaryx \\ y causing coredump=>x \ y causing coredump
    Fri 04 Jun 2010 08:35:57 AM UTChigheggSummaryx \\ y causing coredump=>x \ y causing coredump
    Fri 04 Jun 2010 05:02:59 AM UTCrik5Item GroupNone=>Segfault, Bus Error, etc.
      StatusNone=>Confirmed
      Summaryx \\ y causing coredump=>x \ y causing coredump
    Thu 03 Jun 2010 04:51:08 PM UTCmuhaliAttached File-=>Added foo.ob.bz2, #20684

    Back to the top


    Powered by Savane 3.1-cleanup1