Tue 28 Feb 2012 01:08:27 PM UTC, comment #18:
I pushed jwe's patch
http://hg.savannah.gnu.org/hgweb/octave/rev/933101fd5cbb
|
Sat 25 Feb 2012 08:13:13 PM UTC, comment #17:
Commit the patch. I think FLTK is really coming along as a plot engine for Octave and I'd like to see it reach parity with gnuplot as soon as possible.
|
Sat 25 Feb 2012 06:19:52 PM UTC, comment #16:
I ran all the the demos and produce png files for each one. The only problem isn't new (I can't print the 20th legend.m demo).
If there a no objections, I'd like to push earlier rather than latter so that any potential problems can be identified prior to the 3.8 release (when, I assume, we'll switch the default toolkit to fltk).
|
Sat 25 Feb 2012 04:39:55 PM UTC, comment #15:
I added the patch to the build script
so it is included in the build process
http://cygwin.com/packages/octave/octave-3.4.2-3-src
|
Sat 25 Feb 2012 04:30:10 PM UTC, comment #14:
Ok. I've changed the status to "patch submitted".
By "back ported it to the 3.4.3 release", I assume you are indicating the Cygwin sources for Octave have been patched.
How will this be managed going forward ? Will you need to apply the patch to each new version of Octave until Cygwin fixes its bug ?
Before, taking further action, I'll apply jwe's patch and test it out on MacOS. The fltk toolkit is quite stable for me now, I'm confident I can run Soren's dump_demos() script and identify any regressions.
|
Sat 25 Feb 2012 05:31:21 AM UTC, comment #13:
up to you,
it seems a specific workaround for a cygwin only bug.
I am using it as additional patch for the
cygwin package building, and I already back ported
it to the 3.4.3 release.
You can also close the bug with "patch provided",
as it is a cygwin bug and not a octave one.
|
Sat 25 Feb 2012 01:04:04 AM UTC, comment #12:
ping ... should jwe's patch be pushed ?
|
Tue 13 Sep 2011 09:00:37 PM UTC, comment #11:
it seems fine.
octave:1> graphics_toolkit fltk
octave:2> sombrero
octave:3> cd /tmp/prova
octave:5> print("fltk.epsc","-depsc")
octave:6> print("fltk.psc","-dpsc")
octave:7> print("fltk.pdf","-dpdf")
octave:8> print("fltk.png","-dpng")
octave:9> print("fltk.jpg","-djpg")
octave:10> print("fltk.svg","-dsvg")
octave:12> print("fltk.dxf","-ddxf")
octave:13> print("fltk.emf","-demf")
octave:14> print("fltk.hpgl","-dhpgl")
octave:15> print("fltk.pstex","-dpstex")
octave:16> print("fltk.tikz","-dtikz")
octave:17> print("fltk.aifm","-daifm")
all these formats work and no crash
|
Tue 13 Sep 2011 11:17:21 AM UTC, comment #10:
Is there any reason that flps_renderer::draw needs to work with a file descriptor instead of a FILE pointer? Does the attached patch avoid the problem for you?
(file #23971)
|
Tue 13 Sep 2011 10:49:55 AM UTC, comment #9:
the pclose is where the segfault arise, but
I suspect is not the root cause just a consequence.
Further tracing popen/open/close on the pipe handle/descriptor
I think the sequence is :
- popen in OpenGL_fltk::draw(),
creating pipe 5 and 6 (handle 0x20204F9C)
(pipe 5 is closed as the communication is unidirectional)
- fdopen (6) in glps_renderer::draw
duplicating the handle (new handle 0x2020500C)
- a lot of writing to 6
- fclose (0x2020500C) in glps_renderer::draw
this is causing fclose to call : close(6)
-----------------------------------------------
Run till exit from #0 fclose (fp=0x2020500c)
at ../../../../../src_new/newlib/libc/stdio/fclose.c:116
Breakpoint 6, close (fd=6)
at /pub/cygwin/cvs/src_new/winsup/cygwin/syscalls.cc:1214
------------------------------------------------
- pclose(0x20204F9C) in OpenGL_fltk::draw()
that SEGFAULT's as fd=6 is already closed
The close(6) seems an abnormal beahviour of fclose as
there is another FILE handle still open.
What I don't know if there is a bug in fclose or
if the behaviour is correct due to some settings.
|
Tue 13 Sep 2011 10:25:46 AM UTC, comment #8:
What is the stack trace at the point of the crash?
There is no fhandler_pipe variable in the Octave sources, so where is this crash happening?
If I set a breakpoint in pclose and execute your latest commands, I stop here:
The code in OpenGL_fltk::draw that ultimately calls pclose is
This seems a valid use of popen and pclose. I don't know what fhandler_pipe is or how to set it. Where does it come from and why is it not set but then apparently used?
|
Sat 10 Sep 2011 08:53:15 AM UTC, comment #7:
restarting the search, after long time
the sequence
graphics_toolkit fltk;
x=1:10;
plot (x,x)
print (fltk.png","-dpng")
still causes segfault on octave-dev
The cause is system pclose called with a
NULL handler for the involved pipe
(gdb) p fp
$6 = (FILE *) 0x20204f94
(gdb) call fileno(fp)
$7 = 6
p fh
$8 = (fhandler_pipe *) 0x0
One strange issues:
changing the sequence to
graphics_toolkit fltk;
rand(3);
plot (x)
set (gcf,'visible','off')
print (gcf,"test_invisible.png","-dpng")
set (gcf,'visible','on')
the segfault is not on the print but on the last set
|
Fri 04 Feb 2011 11:35:53 PM UTC, comment #6:
I uploaded on
http://matzeri.altervista.org/works/octave/
the compressed strace for both fltk case that crashes
and gnuplot case that works.
For what I can see, for gnuplot the sequence is
octave > gnuplot > gs > octave (that exit)
while for fltk
octave > gs (unable to return and exit)
Any suggestion how to further investigate ?
|
Fri 04 Feb 2011 07:07:11 PM UTC, comment #5:
I have add Ben to the Mail Notification Carbon-Copy List.
Tatsuro
|
Fri 04 Feb 2011 06:36:03 PM UTC, comment #4:
on 3.2.91-1 build on cygwin 1.7.7 it is enough
x=1:10;
graphics_toolkit ("fltk")
plot(x,x)
print("fltk.png","-dpng")
----------------------------------------------------
9 [main] octave 3792 E:\cygwin2\bin\octave-3.3.91.exe: *** fatal error - Internal error: TP_NUM_C_BUFS too small.
Stack trace:
Frame Function Args
0022D010 6102749B (0022D010, 00000000, 00000000, 00000000)
0022D300 6102749B (61177B80, 00008000, 00000000, 61179977)
0022E330 61004AFB (611C408C, 7C8092EF, 002300D4, 00230000)
0022E350 610ECF78 (0022F5E8, 7C900000, 00000000, 0022E37C)
0022F610 6109540F (612013E0, DF0DF046, 0022F6F0, 0022F5F8)
011A1BDC 6102231D (6F2F6572, 76617463, 2E332F65, 31392E33)
End of stack trace
Hangup
----------------------------------------------------
the file fltk.png is created and it is fine.
|
Thu 03 Feb 2011 05:51:34 PM UTC, comment #3:
I add my mail address in the cc. list
Tatsuro
|
Mon 15 Nov 2010 02:29:47 PM UTC, comment #2:
Under GDB
test_printing("fltk")
[New thread 27684.0x700c]
[New thread 27684.0x1914]
backend is fltk
print fltk-aifm -daifm
[New thread 27684.0x76b8]
Program exited with code 030000000005.
(gdb)
and of course
(gdb) bt
No stack.
|
Sat 13 Nov 2010 03:48:19 PM UTC, comment #1:
I don't see a crash on my Debian system, but I do see the following error:
Can you please try running Octave under gdb and get a backtrace to see precisely where the crash is happening?
|
Sat 13 Nov 2010 03:14:43 PM UTC, original submission:
latest test on
$ hg tip
changeset: 11238:1783b360976f
tag: tip
user: John W. Eaton <jwe@octave.org>
date: Thu Nov 11 02:30:32 2010 -0500
summary: also consider parent classes when checking if class methods are out of date
Print with fltk cause
octave:2> source test_printing.m
octave:3> test_printing("fltk")
backend is fltk
print fltk-aifm -daifm
panic: Segmentation fault -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Segmentation fault
This is happening for any output graphic format.
|