bugGNU Octave - Bugs: bug #34631, MinGW + MSVC - fubarred Octave...

 
 

bug #34631: MinGW + MSVC - fubarred Octave 3.4.+ after many plots

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Sun 23 Oct 2011 07:12:34 PM UTC  
 
Category: PlottingSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Crash
Status: FixedAssigned to: None
Originator Name: Philip NienhuisOpen/Closed: Closed
Release: 3.4.3Operating System: Microsoft Windows

Add a New Comment (Rich MarkupRich 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 23 Aug 2013 08:01:37 PM UTC, comment #14:

I think the bug can be considered fixed, even though I don't think the way fonts are shared is the final implementation. But this problem should not happen anymore.

Due to older freetype version used on RHEL5, I may have to disable font sharing on that platform, but this should not affect Windows.

Michael Goffioul <goffioul>
Project Member
Fri 23 Aug 2013 07:22:52 PM UTC, comment #13:

You mean this bug has been squeezed "in passing"?

Anyway good news, many thanks for fixing Michael. This bug was one of the main showstoppers for getting my colleagues to give Octave a try.

Shall I close this bug or shall we just wait a little longer to check a few more Octave/Windows versions (incl. MSVC)?

Philip Nienhuis <philipnienhuis>
Project Member
Fri 23 Aug 2013 03:16:57 AM UTC, comment #12:

Not puzzling at all. This changeset implements initial font sharing (part of TeX support), which largely mitigate the problem:

http://hg.savannah.gnu.org/hgweb/octave/rev/ba865ea9c7e9

Michael Goffioul <goffioul>
Project Member
Thu 22 Aug 2013 07:38:15 PM UTC, comment #11:

Interestingly, or intruigingly, with a 3.7.6+ MingW build cross-compiled (MXE) yesterday (hg 17304:4c7ee36f591d) this bug doesn't occur. Neither with octave-cli nor with the GUI version.

According to Windows Task manager (WinXP SP3 here) the GUI version starts with around 526 handles, which varies by only a few extra while producing the 34 plots in my example script.
The CLI version starts with 202 handles which slowly climbs to 221.

I doubt if (for this very build) the file handles do matter much - closing all 34 plots just makes one handle close (in Task manager) (both CLI and GUI version).

BUT....
A previous 3.7.5 MXE build (cross-compiled 3 days ago) made with the very same MXE environment (on my Linux box) starts with 201 handles, each plot (w 3 subplots) adds varying amounts of handles (8 - 30) until problems start with 730 handles.

IMO this is definitely a font (overflow) issue - after the 22th plot figure there's no more text added to the plots, and then the number of handles doesn't increase anymore.

Moving the mouse cursor over a plot provokes a lot of the following pair of error messages scrolling over the screen:

Puzzling...

Philip Nienhuis <philipnienhuis>
Project Member
Wed 14 Aug 2013 08:46:29 PM UTC, comment #10:

Thanks, I already figured for a long time it must be a sort of font overload issue (most Windows installations have many more fonts installed than other platforms) but I would never have thought of file handles. Good catch.

My first thoughts on this are "why have multiple file handles open to one and the same font file? can't file handles be shared? or kept in a memory cache? why doesn't this happen on Linux?"

Hopefully this is easy to fix - but it surely is beyond me.

BTW as to comment #9: this bug has re-surfaced in later MXE cross-builds.

Philip Nienhuis <philipnienhuis>
Project Member
 Spam posted by an anonymous
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.

Philip Nienhuis <philipnienhuis>
Project Member
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.

Philip Nienhuis <philipnienhuis>
Project Member
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.

John W. Eaton <jwe>
Project Administrator
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

Nitzan Arazi <nitnit>
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

Michael Godfrey <godfrey>
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

Michael Godfrey <godfrey>
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

Michael Godfrey <godfrey>
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

Michael Godfrey <godfrey>
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.

Philip Nienhuis <philipnienhuis>
Project Member
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).

Philip Nienhuis <philipnienhuis>
Project Member

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by goffioul (Posted a comment)
  • -unavailable- added by jwe (Posted a comment)
  • -unavailable- added by nitnit (Posted a comment)
  • -unavailable- added by godfrey (Posted a comment)
  • -unavailable- added by philipnienhuis (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 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Mon 30 Sep 2013 03:23:21 AM UTCmtmillerDependencies-=>bugs #36548 is dependent
    Fri 06 Sep 2013 10:09:13 PM UTCphilipnienhuisStatusNone=>Fixed
      Open/ClosedOpen=>Closed
    Fri 18 Jan 2013 08:49:10 PM UTCphilipnienhuisSummaryMinGW - fubarred Octave 3.4.+ after many plots=>MinGW + MSVC - fubarred Octave 3.4.+ after many plots

    Back to the top


    Powered by Savane 3.1-cleanup