[Octave-bug-tracker] [bug #37344] GUI Octave freezes when plotting is used with OpenBLAS

[anonymous]

URL:
  <http://savannah.gnu.org/bugs/?37344>

                 Summary: GUI Octave freezes when plotting is used with
OpenBLAS
                 Project: GNU Octave
            Submitted by: None
            Submitted on: Thu 13 Sep 2012 03:29:16 PM UTC
                Category: GUI
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Crash
                  Status: None
             Assigned to: None
         Originator Name: Rüdiger
        Originator Email: address@hidden
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: GNU/Linux

    _______________________________________________________

Details:

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_)




    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?37344>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/