-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
crash in zscal #174
Comments
Thank you for the feedback. We will debug next week Xianyi |
Hi @juliantaylor , I already found the reason for the bug. This bug only happens with multithreading. Thread 0 created a buffer about 32MB. Every thread uses a part of this buffer to storing m complex numbers. In your case, m is 6000*100 about 9.25MB. When OpenBLAS starts 4 threads, it will need 37MB which overflows the buffer. Xianyi |
…d sbmv. Instead of using thread 0 buffer, each thread uses its own sb buffer. Thus, it can avoid overflowing thread 0 buffer.
Hi @juliantaylor , I think I already fixed this bug on develop branch. Could you test it? Xianyi |
seems to work now, thanks |
yet another crash, x86 32 bit in kernel/x86/zscal_sse2.S:131, fedora 11 gcc 4.4.1, git head
and x86_64 in kernel/x86_64/zscal_sse2.S:115, SLC 5.5 gcc 4.4.0, git head
also reproduced on ubuntu 13.10 with gcc 4.7.2 and the openblas package (0.2.5)
the code works perfectly fine with gsl or atlas on all tested platforms
decreasing k to to ~ 600 works,
The text was updated successfully, but these errors were encountered: