bugGNU Octave - Bugs: bug #37344, GUI Octave freezes when plotting...

 
 

bug #37344: GUI Octave freezes when plotting is used with OpenBLAS

Submitted by:  None
Submitted on:  Thu 13 Sep 2012 03:29:16 PM UTC  
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Rüdiger Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  dev
Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Thu 21 Nov 2013 07:48:14 PM UTC, comment #9: 

Closing the report.

Torsten Lilge <ttl>
Project Member
Mon 28 Oct 2013 02:57:30 AM UTC, comment #8: 

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 Miller <mtmiller>
Project Administrator
Sun 20 Oct 2013 07:56:28 AM UTC, comment #7: 

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)

Torsten Lilge <ttl>
Project Member
Thu 10 Oct 2013 05:11:49 PM UTC, comment #6: 

What about an option in the settings dialog? The user can decide what to do and it only affects the GUI mode.

Torsten Lilge <ttl>
Project Member
Thu 10 Oct 2013 01:05:30 PM UTC, comment #5: 

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 Miller <mtmiller>
Project Administrator
Thu 10 Oct 2013 04:45:46 AM UTC, comment #4: 

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?

Torsten Lilge <ttl>
Project Member
Sun 28 Jul 2013 11:06:23 PM UTC, comment #3: 

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

Mike Miller <mtmiller>
Project Administrator
Sun 28 Jul 2013 10:24:30 PM UTC, comment #2: 

If OpenBLAS is deadlocking, isn't the bug there, not in Octave? We don't have several Octave threads calling BLAS functions, do we?

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Sun 28 Jul 2013 07:30:09 PM UTC, comment #1: 

Confirmed on hg revision e7a059a9a644 with Debian openblas 0.2.6-2.

Mike Miller <mtmiller>
Project Administrator
Thu 13 Sep 2012 03:29:16 PM UTC, original submission:  

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)

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #29422:  bug_37344_p01.diff added by ttl (6KiB - text/x-diff)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by jordigh (Posted a comment)
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by None (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2013-11-21 ttl StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2013-10-20 ttl Attached File- => Added bug_37344_p01.diff, #29422
        StatusConfirmed => Patch Submitted
    2013-07-28 mtmiller StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.5