bugGNU Octave - Bugs: bug #44875, Error...

 
 

bug #44875: Error "base_graphics_object::get_properties: invalid graphics object"

Submitted by:  Guillaume <gyom>
Submitted on:  Sat 18 Apr 2015 09:15:42 PM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Fixed Assigned to:  None
Originator Name:  Guillaume 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)

Fri 29 Jul 2016 01:35:56 PM UTC, comment #6:

Thanks.

And yes, these event driven bugs are pretty difficult to fix. Dan is right that we probably need a different approach to dealing with the way the plotting widget accesses interpreter data. As it is now, it seems possible to ask for that data at random times when the graphics objects may not be in a state that is suitable for access.

Closing this report anyway since the immediate problem appears to be fixed and the threading issues are well-known beyond this bug report.

John W. Eaton <jwe>
Project Administrator
Fri 29 Jul 2016 08:57:04 AM UTC, comment #5:

I cannot reproduce the error any more, probably after the fix in bug #46501, so this report can be closed.

Guillaume <gyom>
Sun 17 May 2015 09:22:46 PM UTC, comment #4:

I got this error to happen once, but it is really hard to reproduce. I ran the code in a for loop several hundred times but it only ever happened once. Since I can't reproduce it reliably I just can't help.

Rik <rik5>
Project Administrator
Sat 18 Apr 2015 11:54:39 PM UTC, comment #3:

This doesn't happen on my system, but I believe it is happening with yours and is a problem of a race condition. The uimenu, and drawing elements in general are not the same as the higher level access to dialog boxes and shutdown-confirm that https://savannah.gnu.org/bugs/?44751 bug report addressed. The functions in

scripts/gui
libinterp/corefcn/graphics.cc
libinterp/corefcn/graphics.in.h

are qt/fltk graphics toolkit and use a different approach based upon C++ function callbacks (noting the difference between C++ callback and the Octave function callback which is part of the interpreted language object properties).

It is difficult to pinpoint the problem, but my guess is that it stems from the C++ callback not using a mutex. There is probably a timing issue between the destruction of the Qt menu objects and Octave core redrawing the plot. I don't want to dig into that code as there needs to be thread management for many operations or some type of generic communication protocol across threads. To add, it would make sense to put the rendering code (the OpenGL function calls) in its own separate thread so that the user can rescale the figures while Octave may be running a long processing job.

To redo the plotting in a more robust manner would mean development and instability that would set back 4.0 months for sure, probably a year plus.

I could be wrong, but that's my intuition.

Dan Sebald <sebald>
Sat 18 Apr 2015 09:50:04 PM UTC, comment #2:

I have to say it's a very frustrating one as it appears randomly (and so before and after Dan's patch).
It seems that it is more likely to happen if you had time to see the red panel before it is deleted (unfortunately adding a pause does not help).
I'll try to build a longer example where the error appears with more certainty but even with this example, try a few more times, adding a few return keys in between attempts and a 'clear all'.

Guillaume <gyom>
Sat 18 Apr 2015 09:25:38 PM UTC, comment #1:

Alas, I can't reproduce this. This is on Kubuntu 12.04. I copied and pasted your code 10 times, but never see this problem. If it matters, this is after I applied Dan's patch to deal with thread locking and mutexes.

Rik <rik5>
Project Administrator
Sat 18 Apr 2015 09:15:42 PM UTC, original submission:

I've been observing an error "base_graphics_object::get_properties: invalid graphics object" for a while in a large-ish GUI, when clearing a figure of all its objects, and this with 100% reproducibility. I've tried to trim down a workable example, see below, but sadly, now, the issue is harder to reproduce and the error appears more randomly. Try to copy-paste the following at the Octave prompt, including the carriage return for the last line.

You should see this from time to time:

Guillaume <gyom>

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2016-07-29 jwe StatusNone => Fixed
        Open/ClosedOpen => Closed
    2015-11-23 rik5 Dependencies- => bugs #46501 is dependent

    Back to the top


    Powered by Savane 3.4