bugGNU Octave - Bugs: bug #45469, Program execution stops...

 
 

bug #45469: Program execution stops unpredictably with error in plot statement

Submitted by:  None
Submitted on:  Fri 03 Jul 2015 04:28:54 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Incorrect Result
Status: Need InfoAssigned to: None
Originator Name: ygeOriginator Email: -unavailable-
Open/Closed: OpenRelease: 4.0.0
Operating 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)

Fri 30 Dec 2016 08:00:22 PM UTC, comment #10:

A while ago I fixed the io package for not closing file handles (bug #47378). Maybe this may have interfered; although AFAIK quite a large nr. of file handles needs to be consumed before Octave runs into troubles.

If so newer io package releases should have no influence on this bug's behavior.

Philip Nienhuis <philipnienhuis>
Project Member
Thu 29 Dec 2016 09:56:30 PM UTC, comment #9:

Is there anything open to do with regard to this bug report, or can the report be CLOSED now?

note: This might be a duplicate of bug #46466, which is now fixed in the Octave 4.2.0 release.

Hartmut <hardy>
Wed 08 Jul 2015 06:06:24 PM UTC, comment #8:

I followed your suggestion and have run the program several times in qt-graphics mode. The maximum octave-gui's memory usage during execution did not exceed 210 KB. There are never more than 4 plot windows simultaneously on the screen, since those windows are closed after having saved the contents with the saveas-command to jpg-files. Also the memory usage of other parallel tasks was low.

The program now has run without error with qt-graphics. It seems to be unpredictable, when the reported error will occur. In rare cases the program also crashes for no apparent reason.

Anonymous
Tue 07 Jul 2015 10:23:39 PM UTC, comment #7:

As you are using the 32-bit version, it may also be the case that Octave simply runs out of memory. But as we cannot see your code that's just a guess.
The error messages in your last comment #6 appear to be from Ghostscript.

What you could do is start Task Manager (right-click on the taskbar, select Start Task Manager, click Processes tab, in main menu: View | Select Columns | Memory Working set, and watch octave-gui's memory usage while you make your plots.
Octave's max. array size for the 32-bit version is remarkably low, usually somewhere between 500 and maybe, maybe 750 MB even with many GB of RAM.

Philip Nienhuis <philipnienhuis>
Project Member
Tue 07 Jul 2015 05:56:29 PM UTC, comment #6:

Thank you for your message.

In the meantime after several test runs, I have noticed that the plotting bug #45469 can also occur, when - as described in comment #4 - the ‘pkg load io’ statement is omitted before plotting. Sometimes it works and sometimes not, but the program never runs to the end, when ‘pkg load io’ is entered prior to the program run. Thus there seems to be interference between the io-package and qt-plotting, but obviously the io-package is not the single cause for failure.

For the other graphics toolkits this did not occur so far. When calling graphics_toolkit('fltk') the plots appear on the screen, however, it was not possible to save a single figure as jpg-file with e.g.: saveas(h,['IntAbs_CDIred,smoothed_r' rsc ',nr' nrc '.jpg'],'jpg') .
Each time an error message is produced:

Error: /undefined in -1.#IND
Operand stack:
--nostringval--
Execution stack:
%interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval--
2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false
1 %stopped_push 1951 1 3 %oparray_pop 1950 1 3 %oparray_pop --n
ostringval-- 1934 1 3 %oparray_pop 1820 1 3 %oparray_pop --nostri
ngval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostri
ngval-- 2 %stopped_push --nostringval--
Dictionary stack:
--dict:1188/1684(ro)(G)-- --dict:0/20(G)-- --dict:83/200(L)-- --dict:40/64
(L)--
Current allocation mode is local
GPL Ghostscript 9.16: Unrecoverable error, exit code 1

but program execution continues to the end. So I now use gnuplot: graphics_toolkit('gnuplot') and with this - up to now - the program works under all circumstances. The only disadvantage of gnuplot is, that program execution is slower and the format of figure labelling is not as good (too spacious).

Ciao,
yge

Anonymous
Tue 07 Jul 2015 03:51:08 PM UTC, comment #5:

I do not doubt your descriptions and that what you did works for you, but I find it highly remarkable that the io package can interfere with plotting. But we've been fooled before with thinking things are unlikely....

The only explanation I currently have is something like bug #44998, although that one is for 64-bit Octave. But if this were true it would mean that also for 32-bit Octave the native build chain might be broken/miscompiled.
Luckily it seems this bug has largely been fixed - I'm testing it ATM.

io-2.2.7 in the octave binary installer is indeed broken (see bug #45243).

I'm very curious for the "some minor bugs with the xlswrite-statement". Please report them soon

Philip Nienhuis <philipnienhuis>
Project Member
Mon 06 Jul 2015 05:07:46 PM UTC, comment #4:

Dear Octave community,

Many thanks to all of you for your swift reply on bug report #45469 and your good proposals.

Because of lack of time I am not able right now, to strip down my program to its non-proprietariness and maintaining the reported bug.

The graphics tool used is indeed Qt, and I have not yet done experiments with gnuplot or FLTK. However, I succeeded to circumvent the problem in the way described below. The problem seems to be caused by the interaction of the program with the external package io-2.2.8.tar.gz which I have to load in order to create xlsx-files (Excel) with the xlswrite command.

The Octave 4.0.0 version comes with the io-2.2.7 package (in src sub-directory) but I could not use xlswrite with this. So I downloaded the newer package io-2.2.8.tar.gz from your website.

I entered (some days before, may not be important): pkg uninstall io-2.2.7.tar.gz.
Whenever starting Octave, I have to feed in: pkg install io-2.2.8.tar.gz
with io-2.2.8.tar.gz in my working-directory. When I now enter: “pkg load io”
and run the program, sooner or later the plot error reported in #45469 occurs. So I did the following:

I omit issuing “pkg load io” prior to running the program and instead have this line now in my program immediately before the first xlswrite statement. After the last xlswrite a line: “pkg unload io” is executed. Then the next circle with plot-statements starts and the same sequence for xlswrite is repeated.

With this method the program execution is stable and no errors occur (up to now).

By the way: A similar plot error within a for-loop was reported in #45298, but i could not figure out, if or which io-package was used in that case.

There are some minor bugs with the xlswrite-statement itself, which I will report in another message, so that xlswrite might get fixed in a future issue.

Again, many thanks to all of you for your help,
yge

Anonymous
Sat 04 Jul 2015 07:11:55 AM UTC, comment #3:

It's the Qt toolkit, for sure. I haven't seen a problem, not yet anyway, for FLTK or gnuplot. I'm attaching a simple for-loop that plots random data. Start Octave GUI (change the graphics toolkit if you like to something other than qt if you are curious whether those fail) then run "plot_loop". I eventually run into the error described by the bug report.

I've also had the GUI crash and disappear with the following signal:

[sebald@ octave]$ octave exited with signal 6

If after a half dozen tries everything seems fine, start the loop again and then grab the gui window and drag it over the Qt plot while the loop is processing. That Qt redraw action is probably causing the conflict.

If one removes the comment character from before the pause(0), the loop doesn't seem to cause problems. Or at least it is far less likely to, as I haven't seen it fail in that case.

The error message comes about because the octave_base_value::convert_to_str_internal () is supposed to be overridden by a derivative object, not run from the base class. Some octave_value object without a defined overriding function is being called. But I'm not sure if that is precisely what is happening, or instead maybe the code simply goes off course there. I think this comes back to the similar issue seen previously with Qt plotting and thread management.

Dan Sebald <sebald>
Fri 03 Jul 2015 06:31:36 PM UTC, comment #2:

At least you could say which graphics_toolkit
you are using.

Michael Godfrey <godfrey>
Project Member
Fri 03 Jul 2015 05:51:27 PM UTC, comment #1:

> For proprietary reasons, I cannot send you the full program.


We cannot diagnose a problem that we cannot reproduce.

Please strip down your program to its nonproprietariness so that we can have something reproducible we can attempt to fix.

You can also try to diagnose this yourself by doing debug_on_error(1) and inspecting the local workspace at the point where the error happens.

Jordi Gutiérrez Hermoso <jordigh>
Project Administrator
Fri 03 Jul 2015 04:28:54 PM UTC, original submission:

The program works well with Matlab. Many simple plot statements are executed one after the other. Execution in Octave also produces numerous plots, but after an unpredictable and not reproducible loop number for a plot statement like

plot(frlis,DSlis(:,1),'b-',frlis,DSlis(:,2),'g-');

an error occurs:

line at line 56 column 8
_plt_>__plt2vv__ at line 500 column 10
_plt_>__plt2__ at line 246 column 14
_plt_ at line 113 column 17
plot at line 220 column 10
HF_Evaluation at line 499 column 1
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown
type>'
error: called from
_line_ at line 117 column 21
line at line 56 column 8
_plt_>__plt2vv__ at line 500 column 10
_plt_>__plt2__ at line 246 column 14
_plt_ at line 113 column 17
plot at line 220 column 10
HF_Evaluation at line 499 column 1
error: octave_base_value::convert_to_str_internal (): wrong type argument '<unknown
type>'

For proprietary reasons, I cannot send you the full program. The plots are saved to jpg-files and the figure windows closed after saving, so that only a small amount of figures are open at one time.
My system is Windows 7, 64 bit. I have done several experiments with the io-package, in order to get to work the external xlswrite –statement. But the error now also occurs without loading the io-package.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #34374:  plot_loop.m added by sebald (104B - application/vnd.wolfram.mathematica.package)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by hardy (Posted a comment)
  • -unavailable- added by sebald (Posted a comment)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by jordigh (Posted a comment)
  • -unavailable- added by None (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 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 04 Jul 2015 07:14:05 AM UTCsebaldAttached File-=>Added plot_loop.m, #34374
    Fri 03 Jul 2015 05:51:27 PM UTCjordighItem GroupSegfault, Bus Error, etc.=>Incorrect Result
      StatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1