bugGNU Octave - Bugs: bug #47958, GUI freezes when starting debug...

 
 

bug #47958: GUI freezes when starting debug with a partly drawn Qt figure

Submitter:  Lachlan Andrew <lachlan>
Submitted:  Thu 19 May 2016 11:24:20 AM UTC
   
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Confirmed Assigned to:  None
Originator Name:  Lachlan Open/Closed:  * Open
Release:  * dev Operating System:  * GNU/Linux
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 12 Jan 2019 12:23:04 AM UTC, comment #5: 

Still present.  When I use "Ctrl+C" in the terminal window the GUI suddenly re-activates and I get the following messages


>> debug_on_error (1);
>> a.one = 1;
>> a.two = 2;
>> imagesc (a);
error: invalid value for array property "cdata"
error: called from
    image>__img__ at line 205 column 5
    image at line 125 column 10
    imagesc at line 101 column 12
stopped in /home/rik/wip/Projects_Mine/octave-stable/scripts/image/image.m at line 205
205:   h = __go_image__ (hax, "cdata", img, "xdata", xdata, "ydata", ydata,
debug> error: value on right hand side of assignment is undefined
error: called from
    image at line 125 column 10
    imagesc at line 101 column 12
stopped in /home/rik/wip/Projects_Mine/octave-stable/scripts/image/image.m at line 125
125:     htmp = __img__ (hax, do_new, x, y, img, varargin{chararg:end});
debug>
debug> error: 'htmp' undefined near line 134 column 9
error: called from
    image at line 133 column 3
    imagesc at line 101 column 12
stopped in /home/rik/wip/Projects_Mine/octave-stable/scripts/image/image.m at line 133
133:   if (nargout > 0)
debug>


As you can see from the last bit, it is now in debug mode as expected.

It seems like there is a deadlock, probably over octave_link, where one side is waiting for the other, but the other side believes it has already moved on.

Rik <rik5>
Group administrator
Sun 23 Dec 2018 04:25:21 PM UTC, comment #4: 

I could escape the situation, but the 'Ctrl+C' had to be given in the terminal which started the GUI.  That is not ideal.  If a user has started Octave from a launcher the terminal is no longer even available.

Rik <rik5>
Group administrator
Sat 22 Dec 2018 09:56:24 PM UTC, comment #3: 

The code from comment #0 STILL freezes the GUI when running it in my self compiled version of Octave 5.0.1 (hg-id 9644c0b7efd8) under Ubuntu linux. I acctually could NOT escape it with Ctrl-C from within the GUI terminal.

Hartmut <hardy>
Thu 11 Aug 2016 05:25:35 PM UTC, comment #2: 

This isn't great, but it is a fairly rare occurrence.  I am downgrading the severity of this bug to 3 so it does not block the 4.2 release.

Rik <rik5>
Group administrator
Fri 15 Jul 2016 10:17:52 PM UTC, comment #1: 

Verified, 7/15/16, this code still hangs the GUI.

Rik <rik5>
Group administrator
Thu 19 May 2016 11:24:20 AM UTC, original submission:  

When running from the GUI, the code


debug_on_error (1);
a.one = 1;
a.two = 2;
imagesc (a);


causes the GUI to hang, requiring ^C from the lauching terminal or "force quit" from the window manager.  (Is "crash" the right item group for this?)

Running under gdb gives the following unhelpful stack trace:


Program received signal SIGINT, Interrupt.
0x00007ffff6c6adba in __libc_waitpid (pid=16829, stat_loc=0x7fffffffd160,
    options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:31
31        ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
(gdb) thread apply all bt

Thread 1 (Thread 0x7ffff7fd0780 (LWP 16825)):
#0  0x00007ffff6c6adba in __libc_waitpid (pid=16829, stat_loc=0x7fffffffd160,
    options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:31
#1  0x000000000040194d in main (argc=<optimized out>, argv=<optimized out>)
    at src/main.cc:560


This doesn't occur with FLTK or gnuplot.

If it is run with --no-gui, then the interpreter remains responsive, but the figure window seems to hang (it doesn't redraw on expose events) until debug mode is exited.  After that, it returns to normal.

With "dbstop image 201", i.e., the line


h = __go_image__ (hax, "cdata", img, "xdata", xdata, "ydata", ydata,
                         "cdatamapping", "direct", varargin{:});


running these commands and then typing "dbcont" doesn't cause the freeze.  I thought it may have something to do with the redraw caused by going to the prompt, but putting an explicit "drawnow" before that line doesn't help.  Perhaps it is a timing issue -- however it is more reproducible than I'd expect from a race condition.

Lachlan Andrew <lachlan>

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -email is unavailable- added by hardy (Posted a comment)
  • -email is unavailable- added by rik5 (Updated the item)
  • -email is unavailable- added by lachlan (Submitted the item)
  •  

    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 group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-08-11 rik5 Severity4 - Important 3 - Normal
        StatusNone Confirmed
    2016-07-01 rik5 Severity3 - Normal 4 - Important
    2016-06-23 lachlan Dependencies- bugs #48296 is dependent

    Back to the top

    Powered by Savane 3.13-cf05.
    Corresponding source code