Add a New Comment (Rich Markup)
Comment Type & Canned Response: None None > Multiple Canned Responses Fixed in development Crash with no stack trace Already fixed in newer version Fixed in stable Bad description Bad description and crash Bad stack trace Obsolete version Duplicate and not fixed Duplicate and needs more info Duplicate and fixed Need info and old
( Jump to the original submission )
Closing the report.
Sorry, I forgot to reply to your latest. This bug no longer seems to be present, possibly because of jwe's change to how the GUI is started. I am definitely testing with OpenBLAS and it no longer freezes when plotting.
Mike, is it sufficient to set the variable in the program that uses the openBLAS lib or has it to be set globally? I have attached a patch that provides an option in the settings dialog and sets the environment variable for octave accordingly.
(file #29422)
What about an option in the settings dialog? The user can decide what to do and it only affects the GUI mode.
Yes, both OPENBLAS_NUM_THREADS=1 and OMP_NUM_THREADS=1 prevent the freeze.
I'm not sure if this is something Octave should be setting or not. If it does, it should only be in GUI mode. Both plotting and solving linear equations with openblas works fine in command-line mode.
Mike, did you test whether setting the environment variable OPENBLAS_NUM_THREADS=1 prevents the GUI from freezing? If so, should octave set this variable at startup?
Actually, I was just confirming the behavior reported by the OP, that the GUI freezes when calling a plot routine while OpenBLAS is the active BLAS library.
Now that I did a little bit of stack tracing myself and some searching, maybe it is just a documented feature that this simply won't work?
Quoting from:
https://github.com/xianyi/OpenBLAS/wiki/faq#wiki-multi-threaded
"If your application is already multi-threaded, it will conflict with OpenBLAS multi-threading. Thus, you must set OpenBLAS to use single thread as following..."
For the record, here's the stacktrace I see on the thread that is using up all of the CPU:
#0 0x00007ffff4981f97 in sched_yield () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007fffed6f5785 in exec_blas_async_wait () from /usr/lib/libblas.so.3 #2 0x00007fffed6f5865 in exec_blas () from /usr/lib/libblas.so.3 #3 0x00007fffed6f5e6e in blas_level1_thread () from /usr/lib/libblas.so.3 #4 0x00007fffed3d90cb in dscal_ () from /usr/lib/libblas.so.3 #5 0x00007ffff062cfb1 in dtrti2_ () from /usr/lib/liblapack.so.3 #6 0x00007ffff062e061 in dtrtri_ () from /usr/lib/liblapack.so.3 #7 0x00007ffff5d8f254 in Matrix::tinverse (this=this@entry=0x7fffb07b5ba8, mattype=..., info=@0x7fffd118e0e4: 0, rcon=@0x7fffd118e0e8: 6.9533490695695566e-310, force=force@entry=0, calc_cond=calc_cond@entry=0) at ../../liboctave/array/dMatrix.cc:691 #8 0x00007ffff5d9584a in Matrix::inverse (this=this@entry=0x7fffb07b5ba8, mattype=..., info=@0x7fffd118e0e4: 0, rcon=@0x7fffd118e0e8: 6.9533490695695566e-310, force=force@entry=0, calc_cond=calc_cond@entry=0) at ../../liboctave/array/dMatrix.cc:822 #9 0x00007ffff5d95a9a in Matrix::inverse (this=this@entry=0x7fffb07b5ba8) at ../../liboctave/array/dMatrix.cc:638 #10 0x00007ffff73479df in axes::properties::update_camera (this=this@entry=0x7fffb07b5190) at ../../libinterp/corefcn/graphics.cc:4722
If OpenBLAS is deadlocking, isn't the bug there, not in Octave? We don't have several Octave threads calling BLAS functions, do we?
Confirmed on hg revision e7a059a9a644 with Debian openblas 0.2.6-2.
Using the Octave GUI (hg tip -> 15362:48cb1a5bb64d) with OpenBLAS (0.1alpha2.2-3 on Ubuntu 12.04) causes octave to freeze and use 100% CPU when trying to plot (e.g. stem([1 2 3 4])). It works however fine in --no-gui mode.
Using gdb it seems that there is a deadlock caused in OpenBLAS.
(gdb) bt #0 0x00007ffff69c3c7d in __libc_waitpid (pid=<optimized out>, stat_loc=<optimized out>, options=<optimized out>) at ../sysdeps/unix/sysv/linux/waitpid.c:41 #1 0x00007ffff7f4d69e in dissociate_terminal () at ../../libgui/src/octave-gui.cc:70 #2 octave_start_gui (argc=7, argv=0x7fffffffca48) at ../../libgui/src/octave-gui.cc:81 #3 0x00007ffff692776d in __libc_start_main (main=0x4009e0 <main(int, char**)>, argc=7, ubp_av=0x7fffffffca48, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffca38) at libc-start.c:226 #4 0x0000000000400919 in _start () (gdb) info threads Id Target Id Frame 2 Thread 0x7fffebf98700 (LWP 6155) "lt-octave" pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 * 1 Thread 0x7ffff7ea4780 (LWP 6152) "lt-octave" 0x00007ffff69c3c7d in __libc_waitpid (pid=<optimized out>, stat_loc=<optimized out>, options=<optimized out>) at ../sysdeps/unix/sysv/linux/waitpid.c:41 (gdb) thread 2 [Switching to thread 2 (Thread 0x7fffebf98700 (LWP 6155))] #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 162 ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: No such file or directory. (gdb) bt #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007ffff045adbd in ?? () from /usr/lib/libblas.so #2 0x00007ffff3c04e9a in start_thread (arg=0x7fffebf98700) at pthread_create.c:308 #3 0x00007ffff69f84bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #4 0x0000000000000000 in ?? ()
A workarround is switching to the reference BLAS implementation or setting the number of OpenMP threads to 1 (export GOTO_NUM_THREADS=1)
(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)
Attach Files: Comment:
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Only project members can vote.
Please enter the title of George Orwell's famous dystopian book (it's a date):
Follow 5 latest changes.
Copyright © 2022 Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved. The Levitating, Meditating, Flute-playing Gnu logo is a GNU GPL'ed image provided by the Nevrax Design Team. Source Code
Powered by Savane 3.9