Fri 27 Nov 2015 01:51:53 AM UTC, comment #18:
I'm mark as "Wont Fix" and close it.
|
Thu 26 Nov 2015 05:16:01 AM UTC, comment #17:
Is this bug still relevant? I believe Mac OSX users can now use the qt toolkit which means things have improved dramatically since the reporting of this bug 2 years ago.
|
Thu 16 Jan 2014 05:09:31 PM UTC, comment #16:
Here's a closed duplicate bug with a screen shot and some crash dumps if that weill be helpful to anyone working on this.
Since I can't debug this myself, and I'm comfortable sticking with gnuplot for now, you'll get no further drumbeat from me. But if there is anything concrete I can offer to help illuminate the problem, let me know.
https://savannah.gnu.org/bugs/?41244
|
Mon 18 Nov 2013 01:34:16 AM UTC, comment #15:
If the problem is really what I think it is, meaning OS X does not allow any GUI interaction outside the main thread, then indeed I don't see an immediate solution. By design, it can't work.
|
Sun 17 Nov 2013 10:52:37 PM UTC, comment #14:
Does Michael's comment indicate that there is no possible resolution of this for the 3.8.0 release?
|
Sun 17 Nov 2013 06:53:04 PM UTC, comment #13:
The FLTK backend for octave is designed to run synchronously with the octave interpreter (using the readline event loop); hence it is running in the octave thread.
This is probably a fundamental problem when using the octave GUI, where octave interpreter is not running in the main thread. Mac OS X platform is much more strict (less flexible) in that regard and I believe any GUI interaction must occur in the GUI thread, and must be the main thread.
QtHandles design is different and run the GUI in a separate thread than octave; when a GUI thread (containing the QApplication object) already exists, it hooks up to that GUI thread. Interaction between octave and the GUI is done using non-blocking signal/slot mechanism. This difference in design is why QtHandles works with the GUI in Mac OS X.
|
Sun 17 Nov 2013 04:24:39 PM UTC, comment #12:
>> ... Correct?
That is indeed how I understand it.
>> the proper place?
I don't know if DEFUN functions such as _init_fltk_ can be run out of the interpreter thread (maybe with the new Ffunction mechanism to run DEFUN from C++) but if so it would be worth trying.
|
Sun 17 Nov 2013 04:02:31 PM UTC, comment #11:
Opps ... sorry, I mis-interpreted your prior comment.
Is the main thread for the GUI and the CLI the same? I haven't looked at the code, but my impression is that the octave-gui's ,main thread is the GUI thread, and that octave-cli's main thread is the interpreter. Correct?
Will the interpreter and GUI threads need an if-then-else block on MacOS X to check if the GUI or CLI is running to ensure the toolkit is instantiated in the proper place?
|
Sun 17 Nov 2013 02:53:38 PM UTC, comment #10:
AFAIU, the GUI (not the interpreter) thread is currently the main thread.
I tried to modify octave-gui.cc, and replace QCoreApplication by QApplication in the no-gui section, and "qt" graphics_toolkit now works in "--no-gui" mode also. This means instantiating qt toolkit from the interpreter thread works as soon as QApplication context has been launched from the GUI thread.
If the instantiation of qt/fltk graphic toolkits could be moved to the GUI thread, it would probably solve the problem for fltk indeed.
|
Sun 17 Nov 2013 02:19:11 PM UTC, comment #9:
The GUI thread must be the main thread (interpreter?) on Mac OS X. Thus, I think the instantiation of qt is what needs to be moved.
|
Sun 17 Nov 2013 11:17:08 AM UTC, comment #8:
I have installed QtHandles graphics_toolkit on mac os 10.7 :
- it works just fine with the gui
- crashes with --no-gui ("QWidget: Cannot create a QWidget when no GUI is being used"). This is due to using a QCoreApplication instead of a QApplication in --no-gui mode.
- in cli mode, graphics_toolkit ("qt") returns an error as no QApplication has been initiated.
That tends to make me second Ben interpretation. Even though the figures may be launched from the interpreter thread they use the QApplication context that was instantiated from the main GUI thread. In the case of FLTK the initialization of the GUI is made from the interpreter thread.
Is it possible to Initialise FLTK from the GUI thread (which would make 2 GUI toolkits in the same thread)?
|
Tue 22 Oct 2013 11:41:26 PM UTC, comment #7:
Yes, I have Xcode. After googling about, it appears that Processor.prefPane and hwprefs are part of MacOS 10.5. I'm running MacOS 10.7.5
In any event, I tried the approach you linked to. I turned off hardware multi-threading and set the number of cores to 1. I still encountered the crash.
|
Tue 22 Oct 2013 11:14:30 PM UTC, comment #6:
Do you have Xcode installed? Also, this article is new and suggests another way of limiting the cores that are running http://jesperrasmussen.com/blog/2013/03/07/limiting-cpu-cores-on-the-fly-in-os-x-mountain-lion/
|
Tue 22 Oct 2013 09:21:23 PM UTC, comment #5:
Rik,
I'm not good at interpreting the crash log, but my recollection is that MacOS X requires the gui to run on the main thread. Is the main thread "0" and is FLTK running there?
|
Tue 22 Oct 2013 09:03:10 PM UTC, comment #4:
I haven't been able to locate the file "Processor.prefPane", and the command "hwprefs cpu_ht=false" doesn't work as there is no "hwprefs" in my path.
|
Tue 22 Oct 2013 08:19:30 PM UTC, comment #3:
This is going to be pretty hard to debug. One thought from the crash log is that the drawnow() is called in thread #6 and halts on a lock while thread #0 goes on to segfault. Is there a way to disable multi-threading? I don't know if the FLTK libraries are re-entrant and that could be the problem. I saw this post about disabling hyperthreading (http://superuser.com/questions/467950/how-to-disable-hyperthreading-on-mac-os-x-lion). You might try it and see if (1) it still crashes, and (2) whether there is now only a single thread running when it does. There are other threading mechanisms besides hyperthreading which might need to be turned off as well
|
Tue 22 Oct 2013 06:09:09 PM UTC, comment #2:
Still crashes. The crash log is attached.
(file #29444)
|
Tue 22 Oct 2013 05:59:56 PM UTC, comment #1:
Can you run without any initialization files to make sure that this is a site-specific bug.
|
Fri 11 Oct 2013 02:58:39 PM UTC, original submission:
I'm running MacOS 10.7.5 and am using Macports for all dependencies. From the gui, plotting with the FLTK toolkit causes Octave to crash. The crash log is attached.
|