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.
|
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!
|
Fri 09 Dec 2011 04:00:36 PM UTC, comment #10:
Octave recognizes
as a special case and ultimately calls DSYRK to perform the calculation. For
Octave does not recognize that X+0 is the same as X, so it calls DGEMM to do
in which Y is the result of actually computing X+0.
|
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.
|
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?
|
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.
|
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?
|
Fri 09 Dec 2011 12:38:49 PM UTC, comment #5:
Only thing...how do you account for the differences in comment #2?
|
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.
|
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.
|
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.
|
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]$
|
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 XX' 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.
|