bugGNU Octave - Bugs: bug #65797, adding keyboard command within...

 
 

bug #65797: adding keyboard command within __bar__.m update_data() function causes Octave hang

Submitter:  Nicholas Jankowski <nrjank>
Submitted:  Mon 27 May 2024 02:13:32 AM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Confirmed Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Release: 
Operating System:  * Any Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 04 Jun 2024 03:18:38 AM UTC, comment #3: 

For what it's worth, using the debugger within callbacks has always been problematic, probably for the reasons jwe mentioned.

Rik <rik5>
Group administrator
Mon 27 May 2024 07:34:06 PM UTC, comment #2: 

Ok, this sounds like its not windows specific, so I'll update the tags.  If the summary can be appropriately broadened please do so. 

in the context of my current debugging of the bar subfunctions, is there any logic to why the two keyboard positions behaved so differently?  Should I just avoid using keyboard in the bar subfunctions?  I haven't always  beena able to consistently get regular breakpoints in private functions to behave, and not sure how else to check the listeners on the bar object properties.

Nicholas Jankowski <nrjank>
Group Member
Mon 27 May 2024 05:05:20 AM UTC, comment #1: 

As far as I can tell, this problem happens because of the poor design of the gh_manager class.  I see the main GUI thread blocked at the point that it is attempting to lock the mutex for the gh_manager object.  Then I also see that the interpreter thread is waiting for input, but that doesn't work with the GUI because the main GUI thread appears to be waiting to acquire the mutex.

Instead of this pattern that we are currently using:

  • lock the gh_manager object
  • do some graphics things - might be many things that affect the state of many graphics objects and properties
  • unlock the gh_manager object


we should only be locking the gh_manager object when we make individual modifications (get or set, primarily).  Each of those operations should be fast and should never call any other functions that need to lock the gh_manager object.

It seems to me that the mutex and all locking should be internal to the gh_manager object.  We should not be able to get a reference to the graphics objects and their properties that are managed by the gh_manager class and then modify the contents of those graphics objects directly.  Instead, we should only be able to create, delete, modify, or perform other operations through individual thread-safe functions that only need to do local, limited locking.

Fixing this is a fairly big job but I think it needs to be done, not just to fix this bug, but to avoid other mysterious hangs and/or crashes that could happen with the current design.

We might also use a design similar to the QSettings class to provide thread-safe access to the global gh_manager object itself.

John W. Eaton <jwe>
Group administrator
Mon 27 May 2024 02:13:32 AM UTC, original submission:  

Attempting to work through recent bar bugs, I was running into inexplicable, repeatable Octave hangs that require me to force quite the program. I realized it came from adding a keyboard statement within the update_data subfunction in `__bar__.m`, but only when placed in certain locations and then making a change that triggers the subfunction like setting horizontal to on.

I reverted all of my changes and I can reproduce with a clean stable build:

no crash:

hf = figure;
hax = axes ("parent", hf);
hb = bar (2:4);
set (hb, "horizontal", "on");



no crash:
Adding "keyboard" in _bar_.m at line 527:

##      vertical = strcmp (get (h, "horizontal"), "off");
##      keyboard
##      for i = 1:columns (y)

## save __bar__.m`

close all;  clear all;  clear -f;
hf = figure;
hax = axes ("parent", hf);
hb = bar (2:4);
set (hb, "horizontal", "on");
## will stop in __bar__>update_data at line 527
## F5 will continue without error.


Octave hang:
Remove keyboard added above,  add "keyboard" in _bar_.m at line 535 (the end
of the function before the unwind_protect_cleanup line):

##      endfor
##      keyboard
##      unwind_protect_cleanup

## save __bar__.m`

close all;  clear all;  clear -f;
hf = figure;
hax = axes ("parent", hf);
hb = bar (2:4);
set (hb, "horizontal", "on");
## Octave hangs.


In Windows, the hang produces the spinning circle, grayed out window title, "(Not Responding)" status in title and Task manager.  The Octave title does change to (Debugging), but the CLI never showed the:  "stopped in ..." message with keyboard> prompt.

I know other locations within that subfunctions seemed to cause this as well, but can't seem to figure out why. These were the locations that i could reliably trigger the crash.  I'm not sure why in front of that for block hangs, but after doesn't.

Able to recreate with 9.1.0 and recent stable build (hg id: a1a78e6b2063).  I haven't had a chance to try on linux yet.


Nicholas Jankowski <nrjank>
Group Member

 

(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

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by nrjank (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 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2024-05-27 nrjank StatusNone Confirmed
        Releasestable dev
        Operating SystemMicrosoft Windows Any

    Back to the top

    Powered by Savane 3.14-7003.
    Corresponding source code