Menu
▾
▴
gnuplot-beta
|
From: Daniel J S. <dan...@ie...> - 2017-07-06 18:59:21
|
On 07/06/2017 01:23 PM, sfeam wrote: > On Thursday, 06 July 2017 12:38:13 Daniel J Sebald wrote: >> On 07/05/2017 05:08 PM, Petr Mikulik wrote: [snip] >>> I think that ./configure is the place for tests of compile conditions. >>> There can be some simple case testing whether "-lX11" is needed or not. >>> Is such a workaround possible? >> >> The necessary tests are already present. The hunks of code that matter >> have pre-processor conditionals: >> >> #if defined(WX_NEEDS_XINITTHREADS) && defined(X11) >> #include <X11/Xlib.h> /* Magic fix for linking against wxgtk3.0 */ >> #endif >> >> and WX_NEEDS_XINITTHREADS and X11 are defined from tests within the >> configure process. >> >> We only want to include library -lX11 for the building of wx_gui.cpp, >> and there is a convenient definition for that: >> >> Makefile:LIBRARIES_FOR_X = -lX11 >> >> The included libraries for wx_gui.cpp are gotten from the wx-config >> command as discussed earlier, and it shows up as >> >> Makefile:WX_LIBS = -L/usr/lib/x86_64-linux-gnu -pthread >> -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 >> -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 >> -lwx_baseu_net-3.0 -lwx_baseu-3.0 -lpangocairo-1.0 -lpango-1.0 -lcairo >> -lgobject-2.0 -lglib-2.0 >> >> So, all we really need do is append LIBRARIES_FOR_X to WX_LIBS if >> XInitThreads() is used in the wx_gui code. If X11 is not present, >> LIBRARIES_FOR_X should be empty. >> >> I've attached a six-line patch to the original bug report associated >> with the inclusion of XInitThreads() here: >> >> https://sourceforge.net/p/gnuplot/bugs/_discuss/thread/94192961/d1c5/attachment/gnuplot-wxlibs_xinitthreads_configure-djs2017jul06.patch > > Unfortunately that doesn't work. > > As it shows in the original bug report, wxgtk stupidly insists on the > XInitThreads business *even if the program doesn't use X11*. > > So making gnuplot's configuration rely on LIBRARIES_FOR_X doesn't > resolve the original problem. It just moves the failure from compile-time > to run-time. You can test this by configuring like this: > > ./configure --without-x --without-gd --with-wx > > Your patch allows it to compile without complaint, but then you get > a run-time failure instead because wxgtk aborts when it finds that > XInitThreads was not called. > > This is actually worse than the compile-time failure because at that > point it's too late to fix the problem. > Hence the warning in the Release Notes. I see your point. However, the user is requesting no X11, the consequence of which is a crash. We could drop the "&& defined(X11)" in which case configuration will succeed but compilation then fail. That's probably no better, so in addition to that we could place an error in configure.ac when wx_needs_xinitthreads is "yes" and X11 is not present. > NB: --without-gd is there because the gd configure tool actually gets this right > and pulls in -lX11 if libgd wants it. If the wxgtk configure tool did the same > we wouldn't have this problem. It isn't the wxgtk library that wants X11, it's gnuplot's use of XInitThreads() that requires X11. wxgtk configure can't anticipate our use of an X function. wx_gui shouldn't be using XInitThreads(). I suspect that something in the code outside the main thread is doing something graphics related, but that's much too complex to address in the near term. Dan |
|
From: Ethan A M. <sf...@us...> - 2017-07-06 19:32:23
|
On Thursday, 06 July, 2017 13:59:04 Daniel J Sebald wrote: > On 07/06/2017 01:23 PM, sfeam wrote: > > On Thursday, 06 July 2017 12:38:13 Daniel J Sebald wrote: > >> On 07/05/2017 05:08 PM, Petr Mikulik wrote: > [snip] > >>> I think that ./configure is the place for tests of compile conditions. > >>> There can be some simple case testing whether "-lX11" is needed or not. > >>> Is such a workaround possible? > >> > >> The necessary tests are already present. The hunks of code that matter > >> have pre-processor conditionals: > >> > >> #if defined(WX_NEEDS_XINITTHREADS) && defined(X11) > >> #include <X11/Xlib.h> /* Magic fix for linking against wxgtk3.0 */ > >> #endif > >> > >> and WX_NEEDS_XINITTHREADS and X11 are defined from tests within the > >> configure process. > >> > >> We only want to include library -lX11 for the building of wx_gui.cpp, > >> and there is a convenient definition for that: > >> > >> Makefile:LIBRARIES_FOR_X = -lX11 > >> > >> The included libraries for wx_gui.cpp are gotten from the wx-config > >> command as discussed earlier, and it shows up as > >> > >> Makefile:WX_LIBS = -L/usr/lib/x86_64-linux-gnu -pthread > >> -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 > >> -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 > >> -lwx_baseu_net-3.0 -lwx_baseu-3.0 -lpangocairo-1.0 -lpango-1.0 -lcairo > >> -lgobject-2.0 -lglib-2.0 > >> > >> So, all we really need do is append LIBRARIES_FOR_X to WX_LIBS if > >> XInitThreads() is used in the wx_gui code. If X11 is not present, > >> LIBRARIES_FOR_X should be empty. > >> > >> I've attached a six-line patch to the original bug report associated > >> with the inclusion of XInitThreads() here: > >> > >> https://sourceforge.net/p/gnuplot/bugs/_discuss/thread/94192961/d1c5/attachment/gnuplot-wxlibs_xinitthreads_configure-djs2017jul06.patch > > > > Unfortunately that doesn't work. > > > > As it shows in the original bug report, wxgtk stupidly insists on the > > XInitThreads business *even if the program doesn't use X11*. > > > > So making gnuplot's configuration rely on LIBRARIES_FOR_X doesn't > > resolve the original problem. It just moves the failure from compile-time > > to run-time. You can test this by configuring like this: > > > > ./configure --without-x --without-gd --with-wx > > > > Your patch allows it to compile without complaint, but then you get > > a run-time failure instead because wxgtk aborts when it finds that > > XInitThreads was not called. > > > > This is actually worse than the compile-time failure because at that > > point it's too late to fix the problem. > > Hence the warning in the Release Notes. > > I see your point. However, the user is requesting no X11, the > consequence of which is a crash. We could drop the "&& defined(X11)" in > which case configuration will succeed but compilation then fail. That's > probably no better, so in addition to that we could place an error in > configure.ac when wx_needs_xinitthreads is "yes" and X11 is not present. > > It isn't the wxgtk library that wants X11, it's gnuplot's use of > XInitThreads() that requires X11. wxgtk configure can't anticipate our > use of an X function. No! no! no! You've got this exactly backwards. The _only_ reason gnuplot calls XInitThreads is because otherwise wxgtk aborts. The call was inserted in gnuplot to work around precisely this wxgtk bug. Gnuplot itself makes no other calls into the X11 library. IMHO this is clearly a wxgtk library bug, introduced in version 2.9. If it really wants a call to XInitThreads, let it make that call itself rather than issuing a useless error message and aborting. I'm afraid the reliability of the wxgtk library dropped significantly after version 2.8. See for example Allin Cotrell's problem from earlier today. My recommendation is that if you can link gnuplot against wxgtk 2.8 rather than 2.9 or 3.0 you should do so. Ethan |
|
From: Allin C. <cot...@wf...> - 2017-07-06 19:36:34
|
On Thu, 6 Jul 2017, Daniel J Sebald wrote:
> It isn't the wxgtk library that wants X11, it's gnuplot's use of
> XInitThreads() that requires X11. wxgtk configure can't
> anticipate our use of an X function. wx_gui shouldn't be using
> XInitThreads().
I'd just like to underscore Daniel's last point here. Surely it's a
dangerous hack for the gnuplot code to call XInitThreads() "on
behalf of" wxWidgets (in wxt_gui.h). I suspect this may be related
to the segfault I reported earlier today.
<danger-will-robinson>
#if defined(WXT_MULTITHREADED) && defined(WX_NEEDS_XINITTHREADS) &&
defined(X11)
/* Magic fix needed by wxgtk3.0 */
wxtApp() : wxApp() { XInitThreads(); }
#endif
</danger-will-robinson>
Allin Cottrell
|
|
From: Ethan A M. <sf...@us...> - 2017-07-06 20:14:53
|
On Thursday, 06 July, 2017 15:13:44 Allin Cottrell wrote:
> On Thu, 6 Jul 2017, Daniel J Sebald wrote:
>
> > It isn't the wxgtk library that wants X11, it's gnuplot's use of
> > XInitThreads() that requires X11. wxgtk configure can't
> > anticipate our use of an X function. wx_gui shouldn't be using
> > XInitThreads().
>
> I'd just like to underscore Daniel's last point here. Surely it's a
> dangerous hack for the gnuplot code to call XInitThreads() "on
> behalf of" wxWidgets (in wxt_gui.h). I suspect this may be related
> to the segfault I reported earlier today.
>
> <danger-will-robinson>
> #if defined(WXT_MULTITHREADED) && defined(WX_NEEDS_XINITTHREADS) &&
> defined(X11)
> /* Magic fix needed by wxgtk3.0 */
> wxtApp() : wxApp() { XInitThreads(); }
> #endif
> </danger-will-robinson>
[shrug]
I agree it is stupid that wxgtk does not perform its own initialization.
But it doesn't.
I refer you to the output from wxgtk if this call is omitted:
Call stack:
[00] wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)
[01] wxClientDCImpl::DoGetSize(int*, int*) const
[02] wxBufferedDC::UnMask()
[03] ~wxDC /usr/include/wx-3.0/wx/dc.h:789
[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] 0x7f22e8025ee1
[12] g_closure_invoke
[13] 0x7f22e6af0aad
[14] g_signal_emit_valist
[15] g_signal_emit
[16] gtk_widget_size_allocate
[17] 0x7f22e8024ff3
[18] g_closure_invoke
[19] 0x7f22e6af02c7
[20] g_signal_emit_valist
[xcb] Unknown request in queue while dequeuing
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
I can suggest only 3 other options:
1) Link against wxgtk 2.8 rather than anything newer.
These problems only began after libgtk was substantially revised
in version 2.9
2) Try ./configure --with-wx-single-threaded
This never did much for me, but other people have reported better luck
3) Give up on the wxt terminal and use qt instead
Ethan
|
|
From: Allin C. <cot...@wf...> - 2017-07-06 20:20:45
|
On Thu, 6 Jul 2017, Ethan A Merritt wrote:
> On Thursday, 06 July, 2017 15:13:44 Allin Cottrell wrote:
>> On Thu, 6 Jul 2017, Daniel J Sebald wrote:
>>
>>> It isn't the wxgtk library that wants X11, it's gnuplot's use of
>>> XInitThreads() that requires X11. wxgtk configure can't
>>> anticipate our use of an X function. wx_gui shouldn't be using
>>> XInitThreads().
>>
>> I'd just like to underscore Daniel's last point here. Surely it's a
>> dangerous hack for the gnuplot code to call XInitThreads() "on
>> behalf of" wxWidgets (in wxt_gui.h). I suspect this may be related
>> to the segfault I reported earlier today.
>>
>> <danger-will-robinson>
>> #if defined(WXT_MULTITHREADED) && defined(WX_NEEDS_XINITTHREADS) &&
>> defined(X11)
>> /* Magic fix needed by wxgtk3.0 */
>> wxtApp() : wxApp() { XInitThreads(); }
>> #endif
>> </danger-will-robinson>
>
> [shrug]
> I agree it is stupid that wxgtk does not perform its own initialization.
> But it doesn't.
>
> I refer you to the output from wxgtk if this call is omitted:
>
> Call stack:
> [00] wxOnAssert(char const*, int, char const*, char const*, wchar_t const*)
> [01] wxClientDCImpl::DoGetSize(int*, int*) const
> [02] wxBufferedDC::UnMask()
> [03] ~wxDC /usr/include/wx-3.0/wx/dc.h:789
> [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] 0x7f22e8025ee1
> [12] g_closure_invoke
> [13] 0x7f22e6af0aad
> [14] g_signal_emit_valist
> [15] g_signal_emit
> [16] gtk_widget_size_allocate
> [17] 0x7f22e8024ff3
> [18] g_closure_invoke
> [19] 0x7f22e6af02c7
> [20] g_signal_emit_valist
> [xcb] Unknown request in queue while dequeuing
> [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
> [xcb] Aborting, sorry about that.
>
> I can suggest only 3 other options:
>
> 1) Link against wxgtk 2.8 rather than anything newer.
> These problems only began after libgtk was substantially revised
> in version 2.9
>
> 2) Try ./configure --with-wx-single-threaded
> This never did much for me, but other people have reported better luck
>
> 3) Give up on the wxt terminal and use qt instead
Fair enough. I'll try building against wxgtk 2.8.
Allin Cottrell
|
|
From: Allin C. <cot...@wf...> - 2017-07-06 21:10:53
|
On Thu, 6 Jul 2017, Ethan A Merritt wrote: > I agree it is stupid that wxgtk does not perform its own initialization. > But it doesn't. Granted. However, the problem I've encountered lately is at the other end, wxt_atexit(), and specifically the call thread->Wait() in wxt_gui.cpp. This (but just sometimes, so maybe a race condition?) provokes in wxgtk 3 an assertion failure: "./src/unix/threadpsx.cpp(1480): assert "This() != this" failed in Wait(): a thread can't wait for itself" Is there perhaps a way to guard against that? I'm blissfully ignorant of C++ "this" shenanigans, but maybe something vaguely resembling if (thread != this) // or This() ?? thread->Wait(); Allin Cottrell |
|
From: Daniel J S. <dan...@ie...> - 2017-07-06 21:43:11
|
On 07/06/2017 02:28 PM, Ethan A Merritt wrote: > On Thursday, 06 July, 2017 13:59:04 Daniel J Sebald wrote: >> On 07/06/2017 01:23 PM, sfeam wrote: >>> On Thursday, 06 July 2017 12:38:13 Daniel J Sebald wrote: >>>> On 07/05/2017 05:08 PM, Petr Mikulik wrote: >> [snip] >>>>> I think that ./configure is the place for tests of compile conditions. >>>>> There can be some simple case testing whether "-lX11" is needed or not. >>>>> Is such a workaround possible? >>>> >>>> The necessary tests are already present. The hunks of code that matter >>>> have pre-processor conditionals: >>>> >>>> #if defined(WX_NEEDS_XINITTHREADS) && defined(X11) >>>> #include <X11/Xlib.h> /* Magic fix for linking against wxgtk3.0 */ >>>> #endif >>>> >>>> and WX_NEEDS_XINITTHREADS and X11 are defined from tests within the >>>> configure process. >>>> >>>> We only want to include library -lX11 for the building of wx_gui.cpp, >>>> and there is a convenient definition for that: >>>> >>>> Makefile:LIBRARIES_FOR_X = -lX11 >>>> >>>> The included libraries for wx_gui.cpp are gotten from the wx-config >>>> command as discussed earlier, and it shows up as >>>> >>>> Makefile:WX_LIBS = -L/usr/lib/x86_64-linux-gnu -pthread >>>> -lwx_gtk2u_xrc-3.0 -lwx_gtk2u_html-3.0 -lwx_gtk2u_qa-3.0 >>>> -lwx_gtk2u_adv-3.0 -lwx_gtk2u_core-3.0 -lwx_baseu_xml-3.0 >>>> -lwx_baseu_net-3.0 -lwx_baseu-3.0 -lpangocairo-1.0 -lpango-1.0 -lcairo >>>> -lgobject-2.0 -lglib-2.0 >>>> >>>> So, all we really need do is append LIBRARIES_FOR_X to WX_LIBS if >>>> XInitThreads() is used in the wx_gui code. If X11 is not present, >>>> LIBRARIES_FOR_X should be empty. >>>> >>>> I've attached a six-line patch to the original bug report associated >>>> with the inclusion of XInitThreads() here: >>>> >>>> https://sourceforge.net/p/gnuplot/bugs/_discuss/thread/94192961/d1c5/attachment/gnuplot-wxlibs_xinitthreads_configure-djs2017jul06.patch >>> >>> Unfortunately that doesn't work. >>> >>> As it shows in the original bug report, wxgtk stupidly insists on the >>> XInitThreads business *even if the program doesn't use X11*. >>> >>> So making gnuplot's configuration rely on LIBRARIES_FOR_X doesn't >>> resolve the original problem. It just moves the failure from compile-time >>> to run-time. You can test this by configuring like this: >>> >>> ./configure --without-x --without-gd --with-wx >>> >>> Your patch allows it to compile without complaint, but then you get >>> a run-time failure instead because wxgtk aborts when it finds that >>> XInitThreads was not called. >>> >>> This is actually worse than the compile-time failure because at that >>> point it's too late to fix the problem. >>> Hence the warning in the Release Notes. >> >> I see your point. However, the user is requesting no X11, the >> consequence of which is a crash. We could drop the "&& defined(X11)" in >> which case configuration will succeed but compilation then fail. That's >> probably no better, so in addition to that we could place an error in >> configure.ac when wx_needs_xinitthreads is "yes" and X11 is not present. >> >> It isn't the wxgtk library that wants X11, it's gnuplot's use of >> XInitThreads() that requires X11. wxgtk configure can't anticipate our >> use of an X function. > > No! no! no! > You've got this exactly backwards. > The _only_ reason gnuplot calls XInitThreads is because otherwise > wxgtk aborts. The call was inserted in gnuplot to work around > precisely this wxgtk bug. Gnuplot itself makes no other calls into > the X11 library. > > IMHO this is clearly a wxgtk library bug, introduced in version 2.9. > If it really wants a call to XInitThreads, let it make that call > itself rather than issuing a useless error message and aborting. > > I'm afraid the reliability of the wxgtk library dropped significantly > after version 2.8. See for example Allin Cotrell's problem from > earlier today. My recommendation is that if you can link gnuplot > against wxgtk 2.8 rather than 2.9 or 3.0 you should do so. Things may have simply changed with gtk 3.0 such that it isn't as forgiving in some respects, I don't know. Security issues, etc. I haven't looked at any of WX or GTK code, but I suspect that WX is going a posix route and just doesn't concern itself with the X-windows levels. I'm guessing that because the notes of wxThread state: http://docs.wxwidgets.org/trunk/classwx_thread.html "There are two types of threads in wxWidgets: detached and joinable, modeled after the POSIX thread API." I'm holding off on the conclusion that GTK overlooked using XInitThreads() somewhere because it could be gnuplot's fault for doing graphics in a secondary thread. Maybe the secondary thread is sending some graphics X code through the system that shouldn't be present. That's speculation; but here is what the wxThread documentation says: http://docs.wxwidgets.org/trunk/classwx_thread.html " wxWidgets Calls in Secondary Threads All threads other than the "main application thread" (the one running wxApp::OnInit() or the one your main function runs in, for example) are considered "secondary threads". GUI calls, such as those to a wxWindow or wxBitmap are explicitly not safe at all in secondary threads and could end your application prematurely. This is due to several reasons, including the underlying native API and the fact that wxThread does not run a GUI event loop similar to other APIs as MFC. A workaround for some wxWidgets ports is calling wxMutexGUIEnter() before any GUI calls and then calling wxMutexGUILeave() afterwords. However, the recommended way is to simply process the GUI calls in the main thread through an event that is posted by wxQueueEvent(). This does not imply that calls to these classes are thread-safe, however, as most wxWidgets classes are not thread-safe, including wxString. " The second paragraph above could be very relevant (Qt has this same restriction). This is what I'm trying to figure out: Is wx_gui doing graphics in the secondary thread? The third paragraph too might be important, as I see the following in the custom wxtThread::Entry() function: /* Workaround for a deadlock when the main thread will Wait() for this one. * This issue comes from the fact that our gui main loop is not in the * main thread as wxWidgets was written for. */ wxt_MutexGuiLeave(); I activated FPRINTF() in wxt_gui.cpp to see at what point the process exits prematurely: Terminal type is now 'wxt' Options are '0 enhanced' gnuplot> plot sin(x) Init First Init OnInit OnInit finished First Init2 opening a new plot window secondary thread entry wxtApp::OnCreateWindow wxtFrame constructor wxtFrame constructor 2 frame OnSize panel constructor panel constructor4 wxt_cairo_create_context panel constructor5 panel constructor6 wxtFrame constructor 3 frame OnSize panel OnSize 640 384 7680.000000 7680.000000 wxt_cairo_create_context wxt_cairo_refresh called before window exists new plot window opened Init finished Graphics xmax 12800 ymax 7680 v_char 339 h_char 160 [xcb] Unknown request in queue while dequeuing [xcb] Most likely this is a multi-threaded client and XInitThreads has not been called [xcb] Aborting, sorry about that. gnuplot: ../../src/xcb_io.c:179: dequeue_pending_request: Assertion `!xcb_xlib_unknown_req_in_deq' failed. Aborted It looks like "new plot window opened" might be the source, i.e., wxWindow. Recall there is lag in processing X so it isn't necessarily the last commands that are the source. Again, it takes a little while to digest thread code, but inside wxtThread::Entry() is the following: /* gui loop */ wxTheApp->OnRun(); /* Workaround for a deadlock when the main thread will Wait() for this one. * This issue comes from the fact that our gui main loop is not in the * main thread as wxWidgets was written for. */ wxt_MutexGuiLeave(); Is this "gui loop" indicating that the GUI is in fact being run in the secondary thread? Or is it just launching something from the secondary thread? I'm starting to get the feeling this might explain why I often see the WXT terminal plot windows not close when I exit gnuplot. (It's time consuming to close all windows individually.) So, what I'm going on at this point is: 1) It looks like the graphics may be running in a secondary thread. 2) wxWidgets documentation states "GUI calls are explicitly not safe at all in secondary threads and could end your application prematurely." The contra-positive logic doesn't necessarily conclude that the source of the problem therefore lies in gnuplot. Plus it is a lot of work to test the theory that rearranging wx_gui so that GUI manipulation is only done in the main thread. So, for me it's inconclusive from my understanding just who's responsible for the need for XInitThreads(). Dan |
|
From: Ethan A M. <sf...@us...> - 2017-07-06 22:03:48
|
On Thursday, 06 July, 2017 16:27:00 Daniel J Sebald wrote: > So, what I'm going on at this point is: > > 1) It looks like the graphics may be running in a secondary thread. > > 2) wxWidgets documentation states "GUI calls are explicitly not safe at > all in secondary threads and could end your application prematurely." > > The contra-positive logic doesn't necessarily conclude that the source > of the problem therefore lies in gnuplot. Plus it is a lot of work to > test the theory that rearranging wx_gui so that GUI manipulation is only > done in the main thread. So, for me it's inconclusive from my > understanding just who's responsible for the need for XInitThreads(). > > Dan So do all the errors go away if you do ./configure --with-wx-single-threaded (still omitting the call to XInitThreads and not linking to -lX11). Ethan |
|
From: Daniel J S. <dan...@ie...> - 2017-07-06 22:20:09
|
On 07/06/2017 05:03 PM, Ethan A Merritt wrote: > On Thursday, 06 July, 2017 16:27:00 Daniel J Sebald wrote: > >> So, what I'm going on at this point is: >> >> 1) It looks like the graphics may be running in a secondary thread. >> >> 2) wxWidgets documentation states "GUI calls are explicitly not safe at >> all in secondary threads and could end your application prematurely." >> >> The contra-positive logic doesn't necessarily conclude that the source >> of the problem therefore lies in gnuplot. Plus it is a lot of work to >> test the theory that rearranging wx_gui so that GUI manipulation is only >> done in the main thread. So, for me it's inconclusive from my >> understanding just who's responsible for the need for XInitThreads(). >> >> Dan > > > So do all the errors go away if you do > > ./configure --with-wx-single-threaded > > (still omitting the call to XInitThreads and not linking to -lX11). Yes, on the crash (plot is successful): gnuplot> set term wxt Terminal type is now 'wxt' Options are '0 enhanced' gnuplot> plot sin(x) Init First Init OnInit OnInit finished First Init2 opening a new plot window wxtApp::OnCreateWindow wxtFrame constructor wxtFrame constructor 2 frame OnSize panel constructor panel constructor4 wxt_cairo_create_context panel constructor5 panel constructor6 wxtFrame constructor 3 frame OnSize panel OnSize 640 384 7680.000000 7680.000000 wxt_cairo_create_context wxt_cairo_refresh called before window exists new plot window opened Init finished Graphics xmax 12800 ymax 7680 v_char 339 h_char 160 raise window frame OnSize Graphics xmax 12800 ymax 7680 v_char 339 h_char 160 raise window gnuplot> exit wxt_atexit: handling "persist" setting Checking window 0 : shown parent process: exiting, child process has PID 6255 wxt_cleanup: start wxtApp::OnExit child process: running child process: restarting its event loop panel destructor wxt_cleanup: finished wxt_reset No, on the closing of the plot window at exit. It is still persistent after exit. I'll look into the code around "Checking window 0" if there might be something else at play. Dan |
|
From: Daniel J S. <dan...@ie...> - 2017-07-06 23:33:47
|
On 07/06/2017 05:19 PM, Daniel J Sebald wrote: > On 07/06/2017 05:03 PM, Ethan A Merritt wrote: [snip] >> So do all the errors go away if you do >> >> ./configure --with-wx-single-threaded >> >> (still omitting the call to XInitThreads and not linking to -lX11). [snip] > No, on the closing of the plot window at exit. It is still persistent > after exit. I'll look into the code around "Checking window 0" if there > might be something else at play. OK, this one was O.E. I looked in the window's configuration dialog and saw that there is a "persist" variable active. I must have set that a long time ago not realizing it is remembered between sessions, not present-session-only. Dan |
|
From: Daniel J S. <dan...@ie...> - 2017-07-07 01:08:45
|
On 07/06/2017 05:19 PM, Daniel J Sebald wrote: > On 07/06/2017 05:03 PM, Ethan A Merritt wrote: >> On Thursday, 06 July, 2017 16:27:00 Daniel J Sebald wrote: >> >>> So, what I'm going on at this point is: >>> >>> 1) It looks like the graphics may be running in a secondary thread. >>> >>> 2) wxWidgets documentation states "GUI calls are explicitly not safe at >>> all in secondary threads and could end your application prematurely." >>> >>> The contra-positive logic doesn't necessarily conclude that the source >>> of the problem therefore lies in gnuplot. Plus it is a lot of work to >>> test the theory that rearranging wx_gui so that GUI manipulation is only >>> done in the main thread. So, for me it's inconclusive from my >>> understanding just who's responsible for the need for XInitThreads(). >>> >>> Dan >> >> >> So do all the errors go away if you do >> >> ./configure --with-wx-single-threaded >> >> (still omitting the call to XInitThreads and not linking to -lX11). > > Yes, on the crash (plot is successful): However, wx-single-threaded doesn't work for multiple windows for me. The first plot is fine. But then raise window gnuplot> set term wxt 1 wxt_reset wxt_reset ends Terminal type is now 'wxt' Options are '1 enhanced' gnuplot> plot sin(x) [repeated about 300 times or more] Init opening a new plot window wxtApp::OnCreateWindow wxtFrame constructor wxtFrame constructor 2 frame OnSize Init opening a new plot window wxtApp::OnCreateWindow wxtFrame constructor wxtFrame constructor 2 frame OnSize Init opening a new plot window Segmentation fault Maybe a stack overflow is the segfault. Why it keeps opening new windows (that don't appear visually), I don't know. Dan |
|
From: Daniel J S. <dan...@ie...> - 2017-07-06 23:32:53
|
On 07/06/2017 06:15 PM, Daniel J Sebald wrote: >> No, on the closing of the plot window at exit. It is still persistent >> after exit. I'll look into the code around "Checking window 0" if there >> might be something else at play. > > OK, this one was O.E. I looked in the window's configuration dialog and > saw that there is a "persist" variable active. I must have set that a > long time ago not realizing it is remembered between sessions, not > present-session-only. There is a minor issue, which is that 'persist' and other wxConfig settings are stored at wxt-window exit, rather than at the point of "OK" or "Apply". Say for example: 1) Run 'gnuplot' and generate a WXT terminal window. Exit when 'persist' is active, the window stays on screen. 2) Run 'gnuplot' again, generate a WXT plot and turn off 'persist'. Exit and the most recent plot window closes, but the older plot is still persistent, that's fine. 3) But now close that older plot window and 'persist' is turned back on the next time gnuplot is run. Rare circumstances, and probably not worth a bug fix. Dan |
|
From: <pl...@pi...> - 2017-07-07 17:46:55
|
On 07/07/17 00:32, Daniel J Sebald wrote: > On 07/06/2017 06:15 PM, Daniel J Sebald wrote: >>> No, on the closing of the plot window at exit. It is still persistent >>> after exit. I'll look into the code around "Checking window 0" if there >>> might be something else at play. >> >> OK, this one was O.E. I looked in the window's configuration dialog and >> saw that there is a "persist" variable active. I must have set that a >> long time ago not realizing it is remembered between sessions, not >> present-session-only. > > There is a minor issue, which is that 'persist' and other wxConfig > settings are stored at wxt-window exit, rather than at the point of "OK" > or "Apply". Say for example: > > 1) Run 'gnuplot' and generate a WXT terminal window. Exit when > 'persist' is active, the window stays on screen. > > 2) Run 'gnuplot' again, generate a WXT plot and turn off 'persist'. Exit > and the most recent plot window closes, but the older plot is still > persistent, that's fine. > > 3) But now close that older plot window and 'persist' is turned back on > the next time gnuplot is run. > > Rare circumstances, and probably not worth a bug fix. > > Dan > > ---------- Why is persist being stored anywhere? Surlely this is just flag to gnuplot for whether to close the plot window on the way out. How is this a wxt config option which needs to be stored anywhere. It seems like faulty logic to me. Peter. |
