Fri 18 Jan 2013 08:49:10 PM UTC, comment #9:
Updates:
The 3.6.1 and 3.6.2 MSVC builds have the same bug.
Intruigingly, using the MXE build (cross-compiled from Linux) this bug has disappeared.
Apparently this bug is related to something specific for native Windows build environments.
|
Tue 17 Jan 2012 09:40:16 PM UTC, comment #8:
Tried on Octave-3.6.0 MinGW gcc 4.6.2 (Tatsuro's build):
Using gnuplot:
--------------
Breaks upon plot no. 21 (memory usage at that moment about 102 MB + 20 gnuplot invocations each taking 8 MB (the PC has 1248 MB RAM). Octave prompt is there but doesn't find any command; "path" is empty.
The only accepted command is Ctrl-D which closes all windows + Octave.
Using fltk:
-----------
Goes OK until plot no. 21, then complains about...
...but continues and produces all 34 plots, nos. 23-34 w/o any text.
Memory consumption by Octave at start around 30 MB, around problem moment ~130 MB, after 34th plot around 180 MB. So no problems there, I'd say.
I suspect a memory corruption bug somewhere in the text processing code.
BTW I have another version of the Bruggeman script that hangs Octave-3.6.0 on MandrivaLinux 2010.2.
However, Octave/Linux is more robust as one can enter Ctlr-C after which Octave responds normally again and all plot windows can be closed.
|
Mon 31 Oct 2011 06:01:15 AM UTC, comment #7:
I don't see problems with either of your examples on my Debian system, but opening plot windows when using gnuplot does require a separate gnuplot process and a separate pipe for communication, so those may be counting against some process limits you have.
Also, when using fltk, opening 400 plot windows on my system caused Octave to use around 2GB of memory, so maybe that is causing trouble for you as well.
If the problems are only related to your system running out of resources, then I'm not sure that is a bug in Octave.
With OpenGL graphics, I don't see a problem with adding many text objects to a plot (I tried 10,000 and it worked OK on my system, though it took nearly 10 minutes and caused Octave's virtual process size to grow to around 7GB). However, I don't expect that to work very well at all with gnuplot. Graphics with gnuplot is probably never going to be very efficient, so I would not worry too much about that and instead focus on improving the implementation of graphics with OpenGL.
Even with OpenGL, the resource use might be too high. Maybe we could improve that.
So the first thing to do here is determine whether this is an actual bug in Octave or just a problem with resources that happens to have worse consequences on Windows systems.
|
Sun 30 Oct 2011 08:35:39 PM UTC, comment #6:
I have explored this a bit more and could identify different symptoms from which I can learn that there are at least two type of problems !
Symptom 1 - font related errors
The font related errors are for sure common for both gnuplot and fltk. This can be reproduced with 3.4.3 with both backends by opening a single figure and generating multiple text objects:
figure;
plot(1:10);
max_texts=504;
for ti=1:max_texts
ti
text(rand(1,1)10,rand(1,1)10,sprintf('test_%03u',ti));
end
I could reproduce it on two different machines, an win7-x64 and an xp sp3.
On both machines it fails: with fltk on text object 504 and with gnuplot on text object 503.
With 3.2.4 - it doen't happen with gnuplot but with high number of texts graphics response became very slow.
Symptom 2 - multitude figures problems
max_figures=86;
for ii=1:max_figures,
ii
figure;
plot(1:10);
end
gnuplot:
On WIN7-X64/3.4.3/gnuplot and XP-SP3/3.4.3/gnuplot, I could reproduce it with max_figures>=86
On Win7-X64/3.2.4/gnuplot and XP-SP3/3.4.3/gnuplot, I could reproduce it with max_figures>=256
The error I am getting is:
> error: fputs: invalid stream number = -1
fltk:
On WIN7-X64/3.4.3/fltk I can't since the font related issues appears earlier at figure 102
On WIN7-X64/3.2.4/fltk I can plot many figures but some remain blank.
On the XP-SP3/3.4.3/fltk and XP-SP3/3.2.4/fltk the problems are much more severe:
Octave crashes (disappears) inconsistently between figure 11 to 35. It seems that pause commands between the figure and plot commands tend to get more figures before crashing but I am not sure.
I didn't have a chance to repeat these tests on another XP machine (to eliminate the chance that this XP machine may have a problem with its graphics driver).
I beleive that the font related issues will be easy to be tracked.
The multitude figures issues are not so severe except for the XP/fltk ! (Please repeat the XP/fltk to eliminate the chance that my machine has another problem with system or graphics)
Nitzan
|
Sat 29 Oct 2011 01:54:29 PM UTC, comment #5:
Well, just after I wrote the comment below, the plot
windows all closed and Octave and my X11 session are
back to normal. It took on the order of 10 minutes,
but in the end: no errors. Except for the odd fact
that the close all does not actually happen until
an additional cr is typed. I think this behavior has
been seen elsewhere and is not part of this bug.
So, this may really be Windows-specific after all.
Michael
|
Sat 29 Oct 2011 01:46:18 PM UTC, comment #4:
One additional remark: Now my X11 session is frozen,
not just Octave. So, this may also be an X11 problem,
sorry to say...
Michael
|
Sat 29 Oct 2011 01:43:53 PM UTC, comment #3:
I just tried your max_figs=200; ... script
under devel system and Fedora 14. It generated all
200 plots, it appears to be hung in the closeall in
the sense that it returned to the command prompt, but
the 200 plots have not been closed. And, the command
prompt responded a couple of times but is now hung.
So, there is at least something wrong that is not
Windows specific. This was using fltk/openGL.
Michael
|
Sat 29 Oct 2011 01:29:14 PM UTC, comment #2:
Pillip,
I think that is is useful information. But I also
think that this has been a very long-standing problem.
There was a time when I thought it was, at least in part,
a gnuplot problem. But, this is now obviously not true.
I cannot work on this right now, but I hope it gets
fixed. In a week or two I can try to work on it if
no one else has beaten me to it.
Michael
|
Sat 29 Oct 2011 01:15:46 PM UTC, comment #1:
Inspired by Nitzan's findings I could simplify the test case.
Running:
with either graphics_toolkit one can easily spot at which plot no. Octave gets mixed up.
Changing the max_figs value to a value less than that number, Octave's internal state seems to get reset.
E.g., on my machine (WinXP SP3, Core Duo 2.5 Ghz, 2 GB RAM), with gnuplot, Octave gets mixed up while processing plot 84.
Setting value of max_figs to 82 will allow this loop to be run over and over; so apparently the potentially offending internal state gets reset by a "close all".
With fltk / OpenGL, Octave hangs after the 39th plot.
Hitting <Return> makes Octave disappear (it crashes hard).
By experimenting it turned out that (at least in my case) a value of 19 for max_figs is the max to safely return out of the loop.
So the behavior for gnuplot and fltk is different. I wouldn't know if these are separate bugs.
|
Sun 23 Oct 2011 07:12:34 PM UTC, original submission:
This bug is easy to provoke but I can't put a finger on where the actual bug might be. It has been present al since Tatsuro's Octave-3.3.90_MinGW.
To reproduce:
Download:
http://mflab.googlecode.com/files/Bruggeman7xxSeries.zip
unpack Bruggeman720series.m and plotbrug.m somewhere, and run
Bruggeman720series
This script produces 34 plots, most of them multiple plots in one figure.
(It is made by a colleague, I ported it to Octave for him)
On my boxes I get the following results:
All linux boxes, all Octave versions (3.2.4 - 3.5.+):
-> runs without a hitch and produces the requested 34 plots.
Windows, Octave-3.0.3VC (by Michale Goffioul, I have it still lying around on my hard disk):
-> produces all 34 plots, complains about
but all plots look OK.
Windows, Octave-3.2.4_MinGW:
-> gnuplot: all OK
-> FLTK: all OK, but no text (wasn't implemented at the time)
Windows, Octave-3.4.x_MinGW:
-> breaks after 26th plot (FLTK & gnuplot), yielding:
At this point Octave is fubarred. It can't close the plots anymore:
FYI, LinLibertineG_Re.ttf is a font included with LibreOffice.
Intriguing is that on 3.2.4, w/o implemented text in FLTK, it still ran OK.
I've experimented with looping the first few plot stanzas, only to get the same behavior after a while (40 - 50 plots, depending on what stanzas in Bruggeman720series.m script I had execute in a loop).
|