Tue 19 Aug 2014 08:33:32 AM UTC, comment #59:
This hack was removed from default branch with changeset 8c648c3a2c8f (http://hg.savannah.gnu.org/hgweb/octave/rev/8c648c3a2c8f)
|
Tue 19 Aug 2014 03:46:45 AM UTC, comment #58:
Andreas Weber has recently done a lot of work on the FLTK toolkit and the figure object--menubar, positioning, refresh, the works.
|
Tue 19 Aug 2014 12:01:01 AM UTC, comment #57:
Yes, the hack can be removed.
Btw, what was done to fix this?
|
Mon 18 Aug 2014 10:25:11 PM UTC, comment #56:
Cool. It seems like we can go ahead and remove the temporary hack in figure.m, correct?
|
Mon 18 Aug 2014 10:14:39 PM UTC, comment #55:
With
and
The following commands now work for me.
|
Tue 10 Jan 2012 03:49:46 AM UTC, comment #54:
Works for me under Linux. I'm closing the report now.
|
Tue 10 Jan 2012 01:30:30 AM UTC, comment #53:
Ok. Done.
http://hg.savannah.gnu.org/hgweb/octave/rev/9e6ec5f55827
Please pull and confirm it doesn't break anything for you.
If it works, I think it is ok to close this.
|
Tue 10 Jan 2012 01:03:19 AM UTC, comment #52:
Why don't you go ahead and commit the hack. I'll lower the bug priority right now.
|
Mon 09 Jan 2012 09:54:33 PM UTC, comment #51:
I didn't get the if-block correct in my last reply.
With the diff below
The code below works as expected.
|
Mon 09 Jan 2012 09:48:30 PM UTC, comment #50:
Rik, maybe "if (ismac () && strcmp (get (f, "__graphics_toolkit__"), "fltk"))" ?
In any event, we're sticking to gnuplot as the default backend, so I have no objection to lowering the priority.
|
Mon 09 Jan 2012 07:50:21 PM UTC, comment #49:
Ben, what about the attached patch which applies your hack of using drawnow, but only when on a Mac platform? Otherwise, can we drop the priority for this bug so that it is not a blocker for the 3.6.0 release?
(file #24774)
|
Tue 13 Dec 2011 11:01:22 PM UTC, comment #48:
AFAIK, this is only a problem for fltk-aqua, so it only effects MacOS X.
|
Tue 13 Dec 2011 08:26:04 PM UTC, comment #47:
Same commands run as script also work for me.
|
Tue 13 Dec 2011 08:20:39 PM UTC, comment #46:
Using build from 11 Dec. the commands below
run without problem on Linux Fedora 14.
Is this a windows-only problem?
|
Tue 13 Dec 2011 08:19:50 PM UTC, comment #45:
If I type those command, I get no crash. If they are part of a script, then I get a crash.
The change below prevents the crash, but I don't think this is a proper solution.
|
Tue 13 Dec 2011 08:05:29 PM UTC, comment #44:
Without any of the patches installed, does the following cause a segfault?
|
Tue 13 Dec 2011 07:49:43 PM UTC, comment #43:
Rik
There are some syntax typos in the changeset. The diff below applies for me and run without a parser error.
Unfortunately, I still get the crash.
|
Tue 13 Dec 2011 06:38:57 PM UTC, comment #42:
Ben,
Can you try the attached changset bug31931.cset? It is not a long-term fix, but hopefully is enough to allow the 3.6.0 release to proceed.
The hack is to check for 'visible', 'off' as options to figure() on Mac platforms. If it finds that option pair it deletes them from the initial call to _go_figure_ and then sets 'visible', 'off' on the figure handle that is returned. This probably will cause some flicker.
(file #24584)
|
Mon 12 Dec 2011 09:42:35 PM UTC, comment #41:
Unfortunately, this one is still present.
The backtrace is
|
Mon 12 Dec 2011 08:39:35 PM UTC, comment #40:
Ben, have JWE's recent memory patches fixed this bug too? This bug is currently rated as important which means it is probably a blocker for the 3.6.0 release unless we decide to waive this requirement.
|
Thu 24 Nov 2011 06:22:29 AM UTC, comment #39:
I do not see this problem with current devel
system on Fedora 14 or Fedora16.
Michael
|
Wed 23 Nov 2011 01:27:55 PM UTC, comment #38:
The problem has improved. I tried ...
|
Wed 23 Nov 2011 03:19:59 AM UTC, comment #37:
Bump.
Is this problem still present?
|
Fri 05 Aug 2011 05:27:22 AM UTC, comment #36:
Ben,
Another idea. What graphic card and which OpenGl driver (version) do you use. Is there anythings specific with your setup?
Kai (not logged in)
|
Thu 04 Aug 2011 08:16:35 PM UTC, comment #35:
Unfortunately, I still see the crash.
Perhaps another MacOS user who does not use Fink for dependencies might be recruited to take a look (i.e. maybe its just me / Fink?).
|
Thu 04 Aug 2011 07:12:47 PM UTC, comment #34:
Hmm,
thanks for trying. I am running out of ideas. Can you again check the attached changeset. I have changed the command order in OpenGL_fltk::setup_viewport slightly. Maybe that is the problem here.
Kai
(file #23740)
|
Wed 03 Aug 2011 09:43:19 PM UTC, comment #33:
With the new changeset I see a crash when setting the menu bar.
I encountered a compile error with the changeset
After replacing the colon at the end of line 730 with a semicolon it compiled.
I did not notice your request to try "figure(1,"menubar","figure")" for the prior changeset. Trying it now I see ...
|
Wed 03 Aug 2011 07:29:44 PM UTC, comment #32:
Ben, can you check this changeset as well?
Kai
(file #23737)
|
Tue 02 Aug 2011 06:01:35 AM UTC, comment #31:
Ben,
Does
figure(1,“visible“,“off“,“menubar“,“none“)
also crash?
And if you add
figure(1,“menubar“,“figure“)
Does it crash now?
Kai (not logged in)
|
Mon 01 Aug 2011 08:55:30 PM UTC, comment #30:
With the patch I still encounter the crash. The backtrace is below.
|
Mon 01 Aug 2011 07:02:30 PM UTC, comment #29:
Ben, can you please test the attached changeset (hide.canvas). Now the canvas is hidden, when we try to resize it. Maybe this is the reason for the Mac problems.
Kai
(file #23726)
|
Sun 31 Jul 2011 06:57:00 PM UTC, comment #28:
On Jul 31, 2011, at 2:52 PM, Kai Habel wrote:
>>
>> Ben,
>>
>> am I right that you get the crash when you just do:
>>
>> graphics_toolkit fltk ; figure (1, "visible", "off")
>>
>> Kai
>>
Yes. That is correct.
Ben
|
Sun 31 Jul 2011 06:46:03 PM UTC, comment #27:
Unfortunately, I still see the core dump. My tip is ...
$ hg tip
changeset: 12903:35ea8b9b2a8e
tag: tip
user: Kai Habel <kai.habel@gmx.de>
date: Sun Jul 31 20:15:09 2011 +0200
summary: _init_fltk_.cc: show canvas only, when figure is visible (bug #33321)
The backtrace is below.
|
Sun 31 Jul 2011 06:25:26 PM UTC, comment #26:
I have applied another fix to the default branch (#33321). It solves recent crashes on linux and mingw (32bit) for me. Does this small fix solve the problem for MacOS as well?
Kai
|
Tue 29 Mar 2011 11:09:56 PM UTC, comment #25:
I still get a core dump.
|
Tue 29 Mar 2011 10:24:57 PM UTC, comment #24:
Ben,
Is this bug report still open? It seems like some of the patches may have been applied.
--Rik
|
Mon 07 Feb 2011 07:01:17 PM UTC, comment #23:
With both patches below applied
diffs-canvas-make-current.txt
diffs-5-update.diff
On MacOS, I'm able to run Soren's dump_demos script.
I still encounter a gs crash for the slice.m demo when using the FLTK backend, and encounter a crash for the hold.5 demo #5 for the gnuplot backend. These have always been problems for me.
Without these patches and using FLTK, I see crashes for demo [1] of rose, [2, 3] of scatter, [1, 2, 3] of scatter3, and [1] of slice.
If there are no concerns, I'd like to see these applied.
|
Mon 07 Feb 2011 02:58:25 PM UTC, comment #22:
With the diffs-5.txt patch applied, MacOS does not crash. I needed to modify the patch since fltk_backend.cc no longer exists and _init_fltk_.cc has been modified a bit since the patch was generated.
I've attached the modified version (diffs-5-update.diff). Since the ChangeLog entry didn't apply it is missing. The rest should be ok.
|
Mon 07 Feb 2011 02:34:19 PM UTC, comment #21:
Running Ubuntu 10.05 with the tip, I get a crash for ...
With diffs-canvas-make-current.txt applied I do not.
Unfortunately, on MacOS ...
Should I also apply diffs-5.txt?
|
Mon 07 Feb 2011 08:33:43 AM UTC, comment #20:
I don't know the code well enough to have say if your patch is correct or not. It seems like some OpenGL implementations don't care if a GL context is available, while others crash if one is not. At least my version of FLTK seems to only create a context when we call 'Fl_Window::show ()', which means that the current code is bound to crash when working with invisible figures.
I came up with the attached patch which fixes things for me. It is quite similar to the ones suggested by JWE. However, as I said I don't know the code well enough to make an informed decision here :-(
Søren
(file #22617)
|
Mon 07 Feb 2011 08:05:04 AM UTC, comment #19:
Sorry, I forgot to attach the patch.
Also, any comment from anyone about my previous patch? Is that needed? It has not been checked in yet.
(file #22616)
|
Mon 07 Feb 2011 08:00:59 AM UTC, comment #18:
Does the attached patch help?
I don't see the crash with
alone, but I do see a crash with the figure window invisible.
With the patch, I am able to do
without a crash, but of course the file foo.ps is empty because we can apparently only print things that are shown on the screen. I think that will eventually have to be fixed by generating PostScript (or other) output directly from the figure properties instead of trying to generate output from an OpenGL window.
But anyway, that is a separate issue.
So, should I apply the patch for 3.4?
I have no idea whether it makes sense to make the canvas current before hiding it, but apparently that avoids trouble for you, right?
|
Sun 06 Feb 2011 08:31:29 PM UTC, comment #17:
I've spend a little time on investigating this issue as it really makes FLTK unstable for me. With the current code I see a crash when I do
graphics_toolkit fltk
figure
The crash happens in the call to 'canvas->resize' in 'plot_window::show_menubar'. The issue is that en OpenGL context has not been created at this time, which causes the line
glMatrixMode (GL_PROJECTION);
in 'OpenGL_fltk::setup_viewport' to crash Octave. Thus, the real question is: why has an OpenGL context not been created?
Well, in the 'plot_window' constructor we have the following code
if (fp.get_currentaxes ().ok())
show_canvas ();
else
hide_canvas ();
As I have just called 'figure' from the Octave prompt, there is no plot content and hence no axes. This means that 'show_canvas' is not called. This is important as 'show_canvas' calls 'canvas->make_current ()' which creates the current OpenGL context.
I tried adding
canvas->make_current ();
before the above-mentioned conditional expression in the 'plot_window' constructor and I no longer see the crash and things work for me. I realise that this is most-likely not the correct solution, but hopefully it provides a hint of what the right solution might be.
I hope this is helpful :-)
Søren
|
Thu 20 Jan 2011 10:34:14 PM UTC, comment #16:
I am seeing similar behaviour (as noted in bug #32165). For me the crash happens in line 136 in fltk_backend.cc
glMatrixMode (GL_PROJECTION);
A bit of Google'ing tells me that this usually happens if the frame buffer is not initialised. I tried seeing if I could call glCheckFrameBufferStatus to determine this, but I never managed to persuade the compiler that such a function exists :-(
Is it possible that when we don't have a plot to show, we don't have a frame buffer either?
Søren
|
Thu 20 Jan 2011 09:58:23 AM UTC, comment #15:
I can confirm John's comment #13. I have he same behavior. I will have look.
Kai
|
Fri 14 Jan 2011 12:54:23 PM UTC, comment #14:
I don't know enough to fix this either.
I've changed the status.
|
Fri 14 Jan 2011 07:06:23 AM UTC, comment #13:
I still can't duplicate the crash, but it is not working correctly either.
With my diffs-5.txt patch, I get a window after doing the
but no plot appears. I could use some help from someone who knows more about OpenGL and fltk.
Should we keep the blocker status for this report? It does work correctly for the gnuplot backend. It would be great if it worked for the fltk backend, but I'm not sure that is critical for the release.
|
Tue 21 Dec 2010 01:12:06 PM UTC, comment #12:
Yes, that fixed the crash I was seeing. However, a crash now occurs when "visible" is set to "on.
|
Tue 21 Dec 2010 02:55:10 AM UTC, comment #11:
OK, one more attempt (diffs-5.txt).
(file #22252)
|
Mon 20 Dec 2010 10:47:06 PM UTC, comment #10:
I still encounter the EXC_BAD_ACCESS.
|
Mon 20 Dec 2010 08:34:22 PM UTC, comment #9:
OK, I think I was misreading the backtrace. I've attached another attempt (diffs-4.txt).
(file #22248)
|
Mon 20 Dec 2010 07:36:11 PM UTC, comment #8:
Same result as the last one.
|
Mon 20 Dec 2010 06:49:43 PM UTC, comment #7:
Your crash looks different. I'm attaching a new attempt at a fix (diffs-3.txt). You should remove my first patch and apply this one instead. Does it avoid the problem for you? If not, please post another backtrace.
|
Mon 20 Dec 2010 04:31:53 PM UTC, comment #6:
Unfortunately, I still see the crash on MacOS. I'm using the aqua version of FLTK. Might that be related?
|
Mon 20 Dec 2010 08:44:15 AM UTC, comment #5:
I see now that my patch was not correct to assume that the grahics_handle passed to do_update_canvas was a figure object.
I've attached an updated patch, diffs-2.txt that I think is better, but there still seem to be some problems. For example, I now see the following odd behavior and I don't know how to fix it:
Even if the current implementation loses plots that are generated when visibility is off, I would expect plotting to resume working once visibility is turned on.
If visibility is initially on, toggling works:
What is special about having the visible property off when the figure is created?
(file #22243)
|
Mon 20 Dec 2010 03:06:10 AM UTC, comment #4:
I'm not sure whether it is the best solution, but the attached changeset avoids the crash for me.
(file #22241)
|
Sun 19 Dec 2010 11:15:26 PM UTC, comment #3:
Using hg bisect, I found that the problem was introduced at the following changeset:
+verbatim-
# HG changeset patch
# User Kai Habel <kai.habel@gmx.de>
# Date 1287998803 -7200
# Node ID f0e9befd6a1c90e858838470736e0e283aef4364
# Parent 92a7c136ab350f2362b3a78ed24e802706072afb
add uimenu graphic object to fltk backend
-verbatim-
|
Sun 19 Dec 2010 09:33:02 PM UTC, comment #2:
I'm not seeing the crash immediately after the call to figure, but if I do see a segfault if I do
The beginning of the backtrace is:
|
Sun 19 Dec 2010 09:15:40 PM UTC, comment #1:
works on Fedora 14 x86_64:
octave:1> backend ("fltk"); figure (1, "visible", "off")
octave:2> ans
ans =
{
[1,1] = AutoScaling
[1,2] = ComplexEqn
[1,3] = FinDiffType
[1,4] = FunValCheck
[1,5] = GradObj
[1,6] = Jacobian
[1,7] = MaxFunEvals
[1,8] = MaxIter
[1,9] = OutputFcn
[1,10] = TolFun
[1,11] = TolX
[1,12] = TypicalX
[1,13] = Updating
}
[qss:octave] hg tip
changeset: 11392:757efa1d7e2a
tag: tip
user: Rik <octave@nomad.inbox5.com>
date: Sat Dec 18 14:37:11 2010 -0800
files: doc/ChangeLog doc/interpreter/container.txi doc/interpreter/func.txi doc/interpreter/linalg.txi doc/interpreter/numbers.txi doc/interpreter/signal.txi doc/interpreter/sparse.txi doc/interpreter/stats.txi doc/interpreter/system.txi
description:
Remove deprecated functions from manual.
Michael
|
Sun 19 Dec 2010 08:28:43 PM UTC, original submission:
From gdb, and the backtrace is
|