bugGNU Octave - Bugs: bug #49179, test of...

 
 

bug #49179: test of "plot/util/copyobj.m" hangs

Submitted by:  Hartmut <hardy>
Submitted on:  Sat 24 Sep 2016 08:51:54 PM UTC  
 
Category: Test SuiteSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Regression
Status: DuplicateAssigned to: None
Originator Name: Open/Closed: Closed
Release: 4.2.0Operating System: Microsoft Windows

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 Jump to the original submission)

Thu 17 Nov 2016 06:32:59 PM UTC, comment #21:

Right. Closing as a duplicate of bug #49211.

Mike Miller <mtmiller>
Project Administrator
Thu 17 Nov 2016 01:54:43 PM UTC, comment #20:

Yes this is working reliably now in the 4.2.0 release.

BUT: It only works because jwe undid some improvement to the code. Under Windows the waitpid command now (again) still does nothing at all. So we "let the child zombie army grow" (see bug #49211, comment #4). When I understood that bug report correctly, jwe wanted in the long run to again improve this (maybe by using WaitForSingleObject). So currently (4.2.0 release) we are just using a "quick and dirty" fix.

But since this still open topic is taken care of in bug #49211 you might well close this bug report here, maybe as "duplicate".

Hartmut <hardy>
Thu 17 Nov 2016 06:03:09 AM UTC, comment #19:

If this was caused by waitpid in the release candidate, is it working reliably now with the 4.2.0 release?

Mike Miller <mtmiller>
Project Administrator
Thu 29 Sep 2016 11:39:39 AM UTC, comment #18:

The root cause of this might be bug #49211.

Hartmut <hardy>
Tue 27 Sep 2016 05:22:21 PM UTC, comment #17:

I have tried the print command with the external Gnuplot 5.0.4 and the additional"-dpngcairo" option. As a result I get

  • three error messages from gnuplot (during the "print" command):
  • but the demo script (comment #9) still DOES hang-up! :( This hang-up happens after the three error messages.

Another note:

  • Today I have tried my demo script from comment #9 on a different Win-7 machine, a much faster one. And also there, it hangs (only after round #25, though...) So this seems to happen more easily on slow Win machines, but it does also happen on fast Win machines.
Hartmut <hardy>
Mon 26 Sep 2016 10:42:47 PM UTC, comment #16:

Now since you have a gnuplot with cairo terminals, you can try to exclude ghostscript by changing
print (h1, png1);
to
print (h1, png1, "-dpngcairo");

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Mon 26 Sep 2016 09:24:51 PM UTC, comment #15:

I have downloaded and installed "gp504-win32-mingw.exe" from the mentioned Soureforge site (My Win7 PC is 64bit, but Octave MinGW is 32 bit I think, so I hope this was the right gnuplot version to use). I then used the "gnuplot_binary" command to really use this seperatly installed gnuplot version from within Octave. Result: Those hang-ups are still there!

So we cannot blame the gnuplot binary version that is shipped together with the Octave Windows installer.

Hartmut <hardy>
Mon 26 Sep 2016 09:03:03 PM UTC, comment #14:

Another thing to try is to install a standalon gnuplot
(from https://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.4/)

set gnuplot_binary to the new version and see if the problem
is due to gnuplot included with octave.

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 26 Sep 2016 08:52:14 PM UTC, comment #13:

I have tried to add a delay to ".../m/plot/util/private/__ghostscript__.m", right at the very first line after the "function" line:

  • using pause(1) I still DO see this hang-up
  • using pause(5) I still DO see this hang-up
  • using pause(10) I still DO see this hang-up

I then added a little "disp" command before and after the new "pause" command. This revealed that in the case of a hang-up, Octave never even reaches the function _ghostscript_.m but already hangs-up somewhere EARLIER (during the processing of the print commmand)!

Hartmut <hardy>
Mon 26 Sep 2016 08:25:49 PM UTC, comment #12:

You can try to add delay to
ghostscript_.m

(it should be in <...>/m/scripts/plot/util/private directory)

probably just after "function ..." line.

My guess there is a race condition between gnuplot and ghostscript (that converts ps to png).

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 26 Sep 2016 08:07:10 PM UTC, comment #11:
  • Adding a "PAUSE(1)" directly after the print command does NOT help, I still see the same hang ups. The script never gets to the pause command, in the case when it hangs up during the print command.
    • But I can follow your line of thinking, Dmitry. But the pause should probably be inbetween the generation of the eps-file and the generation of the png file. And this "pause" command (or equivalent) should then be buried somewhere inside the logic of the "print" command for (hidden) gnuplot figures.
  • Switching the figure type to "VISIBLE = on" does NOT prevent this bug, but changes its appearance: In this case I don't see the hang-ups during the print command any more. But I do see hang-ups during the following "close" command. (The png file has been properly created already.) So I would assume that Octave tries to close the figure too early, when it is still being used by the (slow?) print commmand.
  • Switching the figure type to "visible = on" and simultanously using a different graphics_toolkit (QT or FLTK) fully SOLVES the issue. I have never seen any hang-ups here. But this seems to also follow a different path in the print command logic. Here, one type-less file is generated on the way to the png file, but no eps file is used inbetween.

I am now also tempted to guess that this is some kind of timing issue during the print command with gnuplot figures under Win OS. (This is using a slow PC...)

Hartmut <hardy>
Mon 26 Sep 2016 07:34:24 PM UTC, comment #10:

Can you add

pause(1)

after

print (h1, png1);

and try again?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Mon 26 Sep 2016 07:22:06 PM UTC, comment #9:

I have done some further digging in this matter (all on Win7). Here are the results:

  • The problem is with the first test of the tests in copyobj.m.
    • This sometimes hangs up during the "PRINT" command (on an invisible figure).
    • This command is normally creating an eps file from the invisible figure, and this eps file is afterwards transformed into a png file (the eps file is removed then). In the event when the test hangs up, then this eps file is left behind instead. I will attach one of these remainder eps-files, but they look totally fine to me.
    • Further down I will quote a shorter script that is able to reproduce this on my Win7 PC.
  • This first test is always done with the graphics_tookit GNUPLOT.
    • But using a different graphics_tookit of "qt" or "fltk" for this test is currently pointless, because those two toolkits do not seem to support printing of a hidden figure into a file. They both give the following error message instead:

So this whole issue seems to (only) be about

  • printing figures with the "print" command into png-files (or presumable other raster graphic formats)
  • under Windows OS
  • using gnuplot graphics_toolkit
  • (maybe also only with invisible figures)

My CONCLUSION: To me this seems to be relevant to get reproducable results with Octave unit tests under Windows. But on the other side this bug is probably not very relevant for normal Octave users.

Here is the shorter script (shorter than "test copyobj.m") that can create the "hang up" roughly every fifth time on my PC:

(file #38601)

Hartmut <hardy>
Mon 26 Sep 2016 10:59:52 AM UTC, comment #8:

Note the line

so test copyobj always set graphics toolkit to gnuplot.

If I change this line to

or

I get a lot of errors, but octave does not hang.

Avinoam Kalma <avinoam>
Project Member
Sun 25 Sep 2016 11:34:14 PM UTC, comment #7:

@Dmitry: I have also run dump_plot_demos. And yes, it seems to get stuck as well on this Win7 machine. I've only tried once, and it came to fltk - ezsurf03.pnp , but didn't finish this one. Only Ctrl-C could stop it, and it killed the whole Octave process.

Hartmut <hardy>
Sun 25 Sep 2016 11:30:30 PM UTC, comment #6:

I have tried all three different graphics_toolkits, and with ALL of them Octave sometimes "hangs up" as described.

I will paste some "log-files" from this test, maybe this helps to figure out, where the tests hang. Those log-files where generated with test("copyobj.m", "verbose", fid). The hang-up seems to happen at the very end of the test. (Maybe they are even all identical...)

Additionally, at the very bottom of this post, I will paste some error messages that I have seen on screen, when running the test in fully interactive mode with test("copyobj.m", "verbose"), without fid. This might or might not be connected to the above hang-ups. It leads me to the suspicion that some FONT issue might be underlying.

log-file with a "hang up" under graphics_toolkit qt:

log-file with a "hang up" under graphics_toolkit fltk:

log-file with a "hang up" under graphics_toolkit gnuplot:

Screenshot of error messages during fully interactive mode of this test. There where so many similar errors, that the command line history wasn't long enough to show what command started this off at all:

Hartmut <hardy>
Sun 25 Sep 2016 04:02:40 PM UTC, comment #5:

Also, what toolkit are you using during your loop of 10 "test copyobj"? Try switching between gnuplot, qt, and fltk as they each have different issues.

Rik <rik5>
Project Administrator
Sun 25 Sep 2016 07:05:19 AM UTC, comment #4:

Can you run the test with "verbose" and see where it hangs?
I suspect it may be a problem with one of the print()s.
Can you run dump_plot_demos (by Andreas Weber)?

Dmitri.
--

Dmitri A. Sergatskov <dasergatskov>
Sun 25 Sep 2016 06:29:06 AM UTC, comment #3:

For this bug report, I had already done some dozen restarts of Octave. Sometimes my "test copyobj.m" script afterwards went fine for one or two rounds. But I could never get more than 3 succesful tests on copyobj.m in one row. That's why I consider this failure to be (quasi-)reproducible.

And this problem does not exist with my Octave 4.0.3 installation.

Yes, I sometimes can also finish a full _run_test_suite_. But shouldn't it normally just run through? This shouldn't be the exeption but be the normal case to finish all tests just fine.

Hartmut <hardy>
Sun 25 Sep 2016 04:20:24 AM UTC, comment #2:

When I install a new version of Octave and run __run_test_suite__, it always hangs in the first run on test copyobj. After restarting Octave, it hangs on
other tests: hgsave, legend. After a few restarts __run_test_suite__ runs smoothly until the end

Avinoam Kalma <avinoam>
Project Member
Sat 24 Sep 2016 10:17:38 PM UTC, comment #1:

On my box it is the test of hgsave that often hangs directly after installation. (I make cross-builds about every other day these weeks.)

After restarting Octave, __run_test_suite__.m runs to the end w/o issues.

Can you try if restarting Octave fixes your issue?

Philip Nienhuis <philipnienhuis>
Project Member
Sat 24 Sep 2016 08:51:54 PM UTC, original submission:

I installed the current Octave-4.2.0-rc2 Windows installer (from alpha.gnu.org) onto my Win7 machine. When I do _run_test_suite_ after the installation, this run mostly gets stuck for (at least 10) hours at the test of "plot/util/copyobj.m", I just assume it will never finish.

Here is a short script to reproduce this behavior. On my Win-7 machine it never makes it further then step 1, 2 or rarely 3. (One step takes less then 20 seconds if it ever passes.)

If I adjust the path in line 1 properly, and then run the very same script under Octave 4.0.3 (official Windows installer again), then this test passes just fine.

Hartmut <hardy>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by mtmiller (Posted a comment)
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by dasergatskov (Posted a comment)
  • -unavailable- added by avinoam (Posted a comment)
  • -unavailable- added by hardy (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 6 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Thu 17 Nov 2016 06:32:59 PM UTCmtmillerStatusNeed Info=>Duplicate
      Open/ClosedOpen=>Closed
      Dependencies-=>Depends on bugs #49211
    Thu 17 Nov 2016 06:03:09 AM UTCmtmillerRelease4.2.0-rc2=>4.2.0
    Mon 26 Sep 2016 07:22:06 PM UTChardyAttached File-=>Added oct-FXr3kQ_(leftover-eps-file).eps, #38601
    Sat 24 Sep 2016 10:17:38 PM UTCphilipnienhuisStatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1