NaNs produced from dot-product when they should not be

[danpovey]

Guys,
Remember I was talking about some Valgrind errors from reading past the end of an array? I think one of these is producing a NaN, in a dot-product between two vectors of size 11, where the element one past the end (i.e. index 11) is a NaN in one of the two. The dot-product becomes a NaN.

Program received signal SIGFPE, Arithmetic exception.
sdot_k () at ../kernel/x86_64/dot_sse.S:535
535 mulps %xmm8, %xmm5
Current language: auto
The current source language is "auto; currently asm".
(gdb) bt
#0 sdot_k () at ../kernel/x86_64/dot_sse.S:535
#1 0x0000000000501791 in cblas_sdot (n=11, x=0x7f0370, incx=1, y=0x7ef94c, incy=1) at dot.c:91
#2 0x000000000048c903 in kaldi::cblas_Xdot (N=11, X=0x7f0370, incX=1, Y=0x7ef94c, incY=1) at ../matrix/cblas-wrappers.h:46
#3 0x00000000004bae7c in kaldi::VecVec (a=..., b=...) at kaldi-vector.cc:36
#4 0x00000000004857f3 in kaldi::MelBanks::Compute (this=0x7e75a0, power_spectrum=..., mel_energies_out=0x7fffffffca40) at mel-computations.cc:215
#5 0x00000000004822ff in kaldi::Mfcc::Compute (this=0x7fffffffcdc0, wave=..., vtln_warp=1, output=0x7fffffffcf40, wave_remainder=0x0)

at feature-mfcc.cc:106

#6 0x000000000045e0ab in main (argc=8, argv=0x7fffffffe2b8) at compute-mfcc-feats.cc:144

(gdb) up
#1 0x0000000000501791 in cblas_sdot (n=11, x=0x7f0370, incx=1, y=0x7ef94c, incy=1) at dot.c:91

91 ret = DOTU_K(n, x, incx, y, incy);
Current language: auto
The current source language is "auto; currently c".
(gdb) up
#2 0x000000000048c903 in kaldi::cblas_Xdot (N=11, X=0x7f0370, incX=1, Y=0x7ef94c, incY=1) at ../matrix/cblas-wrappers.h:46

46 return cblas_sdot(N, X, incX, Y, incY);
Current language: auto
The current source language is "auto; currently c++".
(gdb) p X
$8 = (const float * const) 0x7f0370
(gdb) p X[0]
$9 = 0.176876217

BTW, don't rely on the fact that I had enabled floating-point exceptions-- I only did that because I had found an example where NaNs were being produced in the program where they should not.

Dan

[juliantaylor]

this looks suspiciously like gh-171

this has to be handled in a more systematic way, e.g. via a testsuite that fills all buffers with NaN's

[xianyi]

Thank you for the suggestion on the testsuite.

Yes, we need create a testcase for NaN.

Xianyi

[xianyi]

Hi all,

I think I fixed the most NAN bugs of dot on x86 64. I will test dot on x86, too.

Xianyi