hi, if the recent cvs version is complied with wxwidgets 3.0 installed on the computer, the resulting binary crashed with the first plot to the wxt terminal. (Crash report is appended.)
This happens regardless of wxwidgets 2.8 also being installed or not. Only after removing the 3.0 package can i make a working build with wxt.
Is wxwidgets 3.0 supposed to work?
I do not recall any reports of either success or failure with wxwidgets3.0
So I guess you get to be the guinea pig :-)
Please write your OS.
On windows 7, gnuplot can be worked with wxwidgets3.0.
This seems to be a bug report of the same crash, or at least a very similar one, without involvment of wxwidgets3
I could not reproduce that one on my Mageia systems, so I really don't know where to start looking for a cause.
System was Xubuntu 14.04.
Should i try if gnuplot465 does the same?
It would be helpful if you can pin down the source of the problem using whatever gnuplot version you like. I suspect it is a wx system configuration issue rather than a gnuplot source code issue, but I could be wrong.
For me, gnuplot also crashes with wxWidgets 3.0 (Debian unstable, amd64). Here, the wxWidgets version can be choosen via
update-alternatives
:It compiles fine, but crashes with a similar report:
A backtrace from gdb looks as follows:
I googled a bit, and this is probably an issue with the multithreading, like the
[xcb] ...
message says.When I enable debugging (used
#define DEBUG 1
instdfn.h
and#define WXTDEBUGINPUT 1
inwxt_gui.cpp
) I can plot something like:but gnuplot crashes later e.g. when zooming by mouse with e.g. the message
It can also happen, that the window freezes completely when zooming by mouse. I guess it'll be very hard to track this down.
I've no experience with multithreading, wxwidgets and such. Hope, these informations are still helpful :)
Christoph
gnuplot 465 crashes identically. Will try compiling my own wxWidgets 3.0 and see if it keeps up. Not this weekend, though, and neither the next. Got a thesis to write. :-)
Should we have a configure option to switch between 2.8 and 3.0, at least until this is resolved?
I don't know how Debian sets it up, but on my system the choice of library versions is all done through wx-config. If you have multiple versions of wxWidgets installed then I suppose you must also have multiple versions of wx-config. Point to whichever one you want and the gnuplot's autoconfigure script should do the rest. That's what the option ./configure --with-wx= is for.
By the way, the last comment attached to this report from a year ago seems to provide a fix for the problem:
http://gnuplot.10905.n7.nabble.com/crash-when-using-wxt-in-Ubuntu-12-04-td17318.html
If someone can confirm that fix and submit a gnuplot patch, that would be great.
I installed wxgtk3.0.0 and rebuilt gnuplot - same bug. I applied the fix suggested in the nabble post above - yes, that seems to fix it.
I'm still getting errors about icon bitmaps. That may be because I skipped some other library update. Plotting works, but there are no widgets visible on the plot window.
Let me know if it works for you. The same fix should probably go into 4.6.
I also found this fix, but hadn't tested it. I had to explicitely link
wxt_gui.o
with-lX11
to compile it, but I get the same error as before. So no, it doesn't work for me.And also compiling with
--with-wx-single-threaded
doesn't help here, I get a segmentation fault in this case.BTW: The option
--with-wx
doesn't work on Debian, I need to useexport WX_CONFIG=/usr/lib/x86_64-linux-gnu/wx/config/gtk2-unicode-3.0
.Last edit: Christoph Bersch 2014-05-20
That doesn't make sense. If it is not already linked and calling into the libX11, how can the original bug be explained as a failure to initialize libX11?
Wait a minute.
What do you mean "link wxt_gui.o with -lX11"? That's not a separate executable so where does the -l flag come in?
Sorry, indeed that doesn't make sense. The linking error happens when the
gnuplot
executable is linked:If I change the Makefile to add an
-lX11
to this command it links correctly.BTW: The option --with-wx doesn't work on Debian, I need to use export WX_CONFIG=/usr/lib/x86_64-linux-gnu/wx/config/gtk2-unicode-3.0.
Yeah, I found that I had to do something of the sort also. The wx-config tool comes in with a different name. But let's not fiddle with the configure script until we figure out how to make wxgtk3 work if selected.
For me it doesn't make sense to work on this problem until I such time as I have a machine where wxgtk3 is configured by default. Installing it on top of my existing setup is triggering too many library incompatibilities for me to take the remaining error messages seriously.
What seems to be happening is that the initial fork of the thread that manages the display window [sometimes] returns too quickly, triggering the "doesn't work without open window" message. On my machines that message looks alarming but is non-fatal. The plots appear as normal despite that initial message. So I'm guessing that this is similar to the issue that some people were having with the initial fork of gnuplot_qt in the qt terminal. If it takes too long to initialize, the main program starts asking for window size information before the display manager is ready. Catching the error and waiting a bit would probably be sufficient, although adding proper synchronization would be better.
We in Debian also switched to wxwidget3.0 and got this problem. The proposed fix on 2014-05-19 from just partly fixes the problem. There are still warnings in a terminal:
==========================
gnuplot -e "set terminal wxt; plot x"
../src/gtk/dcclient.cpp(2041): assert "m_window" failed in DoGetSize(): GetSize() doesn't work without window [in thread 7f908b5b0700]
Call stack:
[00] wxOnAssert(char const, int, char const, char const, wchar_t const)
[01] wxClientDCImpl::DoGetSize(int, int) const
[02] wxBufferedDC::UnMask()
[03] 0x7f9099ec8513
[04] wxAppConsoleBase::CallEventHandler(wxEvtHandler, wxEventFunctor&, wxEvent&) const
[05] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, wxEvtHandler, wxEvent&)
[06] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[07] wxEvtHandler::TryHereOnly(wxEvent&)
[08] wxEvtHandler::ProcessEventLocally(wxEvent&)
[09] wxEvtHandler::ProcessEvent(wxEvent&)
[10] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[11] 0x7f9098f6adf1
[12] g_closure_invoke
[13] 0x7f90981afd3d
[14] g_signal_emit_valist
[15] g_signal_emit
[16] gtk_widget_size_allocate
[17] 0x7f9098f69f03
[18] g_closure_invoke
[19] 0x7f90981af557
[20] g_signal_emit_valist
Segmentation fault
==========================
The gnuplot version is 4.6.5, 5.0 was not tested.
Looks like the wxwidgets people have responded to this bug report with "won't fix". I do not understand the logic or the decision, but here is a link to the tracker item:
Yay. I finally have a machine to work on that has wxWidgets 3.0 and supporting libraries properly configured so that I can work on this. Following the hints given in the wxwidgets tracker item above, I think I have managed to protect against this failure mode.
I believe there is a wxwidgets bug involved (intrinsic function IsShownOnScreen() does not work as documented), but we can work around this by using our own window bookkeeping variables.
Fix committed to cvs for both 5.0 and 5.1
Please test.
Is the makefile still broken? I get the error "undefined reference to symbol XInitThread" mentioned above (xubuntu 14.10).
The makefile is not broken, but the library requirements listed by wx-config-3.0 are incomplete.
From the gnuplot version 5 release notes:
If you configure in the wxt terminal without also configuring in X11,
you may need to set the environmental variable TERMLIBS:
TERMLIBS="-lX11" ./configure
Ah. Got it. gp5
01-cvs now builds successfully with wxt3 (on xubuntu 14.10 here) afterTERMOPT="-X11" ./configure
however, the binary is a bit shaky. From time to time after a plot command (sometimes reproducible, e.g. when hitting any button in the terminal window triggering a replot) there is a warning
(gnuplot:2852) Glib-Critical **: Source ID 269 was not found when attempting to remove it.
The positions in gnuplot varies between different runs. That "Source ID" increases with every warning. At one time gnuplot crashed. (any idea where the crash log is? i thought it´d be in the current directory?)
Last edit: Karl Ratzsch 2014-12-15