bugGNU Octave - Bugs: bug #35021, Floating point exception on matrix...

 
 

bug #35021: Floating point exception on matrix multiplication

Submitted by:  Melvin Robinson <melrobin>
Submitted on:  Fri 09 Dec 2011 01:01:33 AM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Invalid Assigned to:  Jordi Gutiérrez Hermoso <jordigh>
Originator Name:  melrobin Open/Closed:  Closed
Release:  3.4.3 Operating 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)

Fri 09 Dec 2011 10:45:53 PM UTC, comment #12: 

Never mind about the Octave call to dsyrk.  I was able to write a tester and reproduce this error and it has been confirmed as a bug in the parallel ATLAS library. 

Thank you for helping me narrow this down to dsyrk.

Melvin Robinson <melrobin>
Fri 09 Dec 2011 06:05:24 PM UTC, comment #11: 

This is great information!  Will you give me the exact parameters that dsyrk would be called with in this case?  I am going to write a small tester with my data matrix to send to the ATLAS developers. 

Hopefully they can find the difference between the way this is implemented in the serial library and the parallel one.

The matrix in the attached coredump.mat is 1768x19.  I just did not know how Octave would handle the UPLO and T parameters for this problem.  The rest seem straightforward though.

Thanks for your help!

Melvin Robinson <melrobin>
Fri 09 Dec 2011 04:00:36 PM UTC, comment #10: 

Octave recognizes

X'*X

as a special case and ultimately calls DSYRK to perform the calculation.  For

(X+0)'*X

Octave does not recognize that X+0 is the same as X, so it calls DGEMM to do

Y'*X

in which Y is the result of actually computing X+0.

John W. Eaton <jwe>
Project Administrator
Fri 09 Dec 2011 02:35:14 PM UTC, comment #9: 

http://en.wikipedia.org/wiki/Nasal_demon

"When an instance of undefined behavior occurs, so far as the language specification is concerned anything could happen, maybe nothing at all."

It is folly to attempt a careful analysis of a problem by examining what particular UB it causes. UB only tells you that something is wrong, may sometimes point to the general location of the problem, or may occur in a completely unrelated location. "Everything works fine" is just another expression of UB.

I am going to tentatively close this as a bug with ATLAS, not with Octave. If you get a response from ATLAS that indicates that Octave is doing something wrong, we can reopen this report.

Jordi Gutiérrez Hermoso <jordigh>
Project AdministratorIn charge of this item.
Fri 09 Dec 2011 02:25:39 PM UTC, comment #8: 

What is UB?  Do I really want to know? :)

No, the problems seem to have gone away when rebuilding with the serial library.  I opened a ticket with them and hope to help troubleshoot this issue some more. 

The configure options that I used for Octave are:
--with-lapack=-lptlapack --with-blas=-ltatlas

which are the parallel versions created with the ATLAS build.

So, Octave would receive these fp exceptions from the ATLAS routines.  Is there a way to find out more information?

Melvin Robinson <melrobin>
Fri 09 Dec 2011 02:18:33 PM UTC, comment #7: 

Comment #2 just sounds like standard UB to me... UB sometimes "works", sometimes doesn't. It is the way of nasal demons.

So you are saying that you don't experience problems with the serial library?

I am not sure what the parallel build of ATLAS is doing. I can tell you that Octave right now is hopelessly single-threaded. I don't know if this matters as far as an Octave library being multi-threaded or not.

Jordi Gutiérrez Hermoso <jordigh>
Project AdministratorIn charge of this item.
Fri 09 Dec 2011 01:51:44 PM UTC, comment #6: 

I rebuilt Octave against the same version of ATLAS (3.9.56); however, I built it against the serial libraries instead of the parallel ones.  The problem does not occur when doing this.

Does this indicate a problem with ATLAS? If so, the Octave interpreter should send the same matrices to the ATLAS routines when computing X'*X as (X+0)'*X, shouldn't it?

If there is a problem with ATLAS I would like to get as much information to those folks as possible so how can I get some low level (debug) information to them?

Melvin Robinson <melrobin>
Fri 09 Dec 2011 12:38:49 PM UTC, comment #5: 

Only thing...how do you account for the differences in comment #2?

Melvin Robinson <melrobin>
Fri 09 Dec 2011 12:34:49 PM UTC, comment #4: 

I did build against a developer version of ATLAS which is using LAPACK 3.4.0.  I can try against some other versions of ATLAS and use the LD_LIBRARY_PRELOAD.

Melvin Robinson <melrobin>
Fri 09 Dec 2011 08:25:36 AM UTC, comment #3: 

You say you built your own ATLAS? This sounds like user error in building ATLAS. Do you have a pre-built ATLAS you can test against? Use LD_LIBRARY_PRELOAD to try a different ATLAS.

Jordi Gutiérrez Hermoso <jordigh>
Project AdministratorIn charge of this item.
Fri 09 Dec 2011 02:45:44 AM UTC, comment #2: 

Here is some more simple troubleshooting:

octave:1> load coredump.mat
octave:2> (X+0)'*X;
octave:3> X'*X;
panic: Floating point exception -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Floating point exception (core dumped)
[melrobin@melrobin nn]$

I think that this is very weird and don't know where to start in fixing.

Melvin Robinson <melrobin>
Fri 09 Dec 2011 02:40:06 AM UTC, comment #1: 

Just as an experiment, I did (X+1)'*X and it did not core dump.

Here are the results of the experiment:
octave:1> load coredump.mat
octave:2> (X+1)'*X;
octave:3> X=X+2;
octave:4> X'*X;
panic: Floating point exception -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Floating point exception (core dumped)
[melrobin@melrobin nn]$

Melvin Robinson <melrobin>
Fri 09 Dec 2011 01:01:33 AM UTC, original submission:  

I receive a floating point exception when doing a simple matrix multiply:
octave:1> load coredump.mat
octave:2> X'*X
panic: Floating point exception -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Floating point exception (core dumped)

The above are the result of narrowing down the core dump.  Strangely X*X' does not fail, but X'*X does.  I did try this on the Octave for Windows version 3.2.4 and it did not crash. 

Attached is the core dump file.  Could someone please take a look at this and tell me what I possibly have done wrong?  I built this version of octave from source with ATLAS.

Melvin Robinson <melrobin>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #24550:  coredump.mat added by melrobin (394KiB - application/octet-stream)
file #24551:  octave-core added by melrobin (263KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by melrobin (Submitted the item)
  • -email is unavailable- added by melrobin
  •  

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

    Only project members can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-12-09 jordigh StatusNeed Info => Invalid
        Open/ClosedOpen => Closed
    2011-12-09 jordigh StatusNone => Need Info
        Assigned toNone => jordigh
    2011-12-09 melrobin Attached File- => Added coredump.mat, #24550
        Attached File- => Added octave-core, #24551
        Carbon-Copy- => Added melrobin

    Back to the top


    Powered by Savane 3.5