bugGNU Octave - Bugs: bug #53328, "test getframe" may fail...

 
 

bug #53328: "test getframe" may fail when the CPU load is large

Submitted by:  Pantxo Diribarne <pantxo>
Submitted on:  Mon 12 Mar 2018 09:16:06 AM UTC  
 
Category:  Plotting with OpenGL Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Unexpected Error
Status:  Fixed Assigned to:  None
Originator Name:  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)

Mon 16 Apr 2018 03:14:37 PM UTC, comment #17:

That's a good thing as there isn't much time before the 4.4 release.

Rik <rik5>
Project Administrator
Mon 16 Apr 2018 02:52:32 PM UTC, comment #16:

My apologies, for some reasons the patch was not applied during my tests. It works fine and couldn't observe any failure.

Guillaume <gyom>
Wed 11 Apr 2018 03:24:15 PM UTC, comment #15:

Just to point out that I still observe failures from time to time. I first noticed 'make check' failing for the first test in getframe, then running test('getframe') with './run-octave', I get about 1/1000 failures, while they are more frequent with './run-octave --gui' (1/1000 to 1/10 failures).

Guillaume <gyom>
Fri 30 Mar 2018 05:29:19 PM UTC, comment #14:

The patch works for me. I tested while building MXE octave, a copy of Octave for Linux, and grepping in the source tree. 10,000 / 10,000 tests passed. I committed the change here (http://hg.savannah.gnu.org/hgweb/octave/rev/6bc4958b224b).

Closing report.

Rik <rik5>
Project Administrator
Fri 30 Mar 2018 09:09:42 AM UTC, comment #13:

I attached a patch implementing the retry/wait workaround. With this I get no failure with the original test procedure (4 Octave sessions).

(file #43723)

Pantxo Diribarne <pantxo>
Project Member
Thu 29 Mar 2018 08:07:14 PM UTC, comment #12:

I do not get failures if I add pause(0.1) after
hf = figure ("visible", "off");
(in the test section)

I am not sure if this is a better "fix" or not.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Thu 29 Mar 2018 07:58:44 PM UTC, comment #11:

@Rik: 1 retry and no delay between first and second call. I'll try with a delay like for opengl_info.

Pantxo Diribarne <pantxo>
Project Member
Thu 29 Mar 2018 07:54:22 PM UTC, comment #10:

@Pantxo: 1 or 2 failures in 4000 would still be an improvement. That equates to 2.5-5 failures in 10,000 and I was seeing 30 failures in 10,000 before. It certainly isn't the complete solution, but we could use it for now. And was that with 2 retries or 3?

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 07:26:03 PM UTC, comment #9:

Yes, I tried and I still get 1 or 2 failures among 4000 (4 octave sessions running the original example in parallel) ...

I also tried to use QTimer and push this call last in the Qt event queue (and eventually flush pending operations on the Figure object) to no avail.

Pantxo Diribarne <pantxo>
Project Member
Thu 29 Mar 2018 07:20:42 PM UTC, comment #8:

Longer term, I'm going to try to revise the QtHandles code. The Object/ObjectProxy thing looks unnecessarily complicated to me.

John W. Eaton <jwe>
Project Administrator
Thu 29 Mar 2018 07:19:48 PM UTC, comment #7:

We already do a similar thing with the _opengl_info_ function. It tries up to three times with a small delay between each attempt. If doing something like that helps to avoid the problem with getframe, then I think it would be OK as a temporary fix.

John W. Eaton <jwe>
Project Administrator
Thu 29 Mar 2018 07:14:26 PM UTC, comment #6:

What about trying twice? Call invokeMethod and if the status is false call it again immediately assuming that it was just a temporary glitch. If there are two failures in a row then issue a warning.

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 07:07:28 PM UTC, comment #5:

I tracked the issue down to ObjectProxy.cc. We use the following contruct to call a function in the GUI thread from the interpreter and retrieve a return value:

Sometimes this function fails and the "slotGetPixels" in the GUI thread never gets executed. QMetaObject::invokeMethod returns false if it fails, this could be used to explicitly warn about the failure, but I didn't find a clue on the actual reason for the failure.

Pantxo Diribarne <pantxo>
Project Member
Thu 29 Mar 2018 06:02:00 PM UTC, comment #4:

Adding jwe to this bug report. This bug needs some work, or we are going to just have to accept some failures in the test suite for the 4.4 release. We already did that once with osmesa and that led to a lot of heartache.

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 04:23:28 AM UTC, comment #3:

Unfortunately, the problem still persists even with jwe's fix for the other two bugs.

Rik <rik5>
Project Administrator
Thu 29 Mar 2018 12:10:14 AM UTC, comment #2:

I just ran 10,000 cycles while compiling MXE Octave. I got 9970 successes. That is pretty good, but still 0.3% failure and I don't know why. jwe just fixed bug #53500, bug #53847 so I will re-test.

Rik <rik5>
Project Administrator
Mon 12 Mar 2018 01:35:44 PM UTC, comment #1:

As I mentioned in other thread -- it does not look like CPU load but some I/O (interrupt latency) load which is matter.
E.g. running few busy loops with pegs CPU load to max (400%)
does not increase failure rate noticeably. But running "make check" (that keeps cpu load to 50%) does.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 12 Mar 2018 09:16:06 AM UTC, original submission:

Launching a few (say 4) octave sessions and running the following in each one shows some test failures:

The image returned by "getframe" is empty. What is really intriguing is the absence of warning (see bug #53186). I'll try and look into this tonight.

Pantxo Diribarne <pantxo>
Project Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #43723:  getframetest.patch added by pantxo (2KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Date Changed by Updated Field Previous Value => Replaced by
    2018-03-30 rik5 StatusPatch Submitted => Fixed
        Open/ClosedOpen => Closed
    2018-03-30 pantxo Attached File- => Added getframetest.patch, #43723
        StatusConfirmed => Patch Submitted
    2018-03-29 rik5 Carbon-Copy- => Added jwe
    2018-03-29 rik5 StatusNone => Confirmed

    Back to the top


    Powered by Savane 3.3