Menu
▾
▴
gnuplot-beta
|
From: Allin C. <cot...@wf...> - 2014-11-15 17:36:29
|
I just tried out the file save button in the gnuplot wxt window. It works nicely... except that I'm seeing a delay of up to 40 seconds between clicking the button and the file-save dialog opening. This is on a lightly loaded system, with gnuplot launched via gnuplot -persist <plotfile>. -- Allin Cottrell Department of Economics Wake Forest University, NC |
|
From: Daniel J S. <dan...@ie...> - 2014-11-15 18:08:09
|
On 11/15/2014 11:55 AM, Allin Cottrell wrote: > On Sat, 15 Nov 2014, Daniel J Sebald wrote: > >> On 11/15/2014 11:36 AM, Allin Cottrell wrote: >>> I just tried out the file save button in the gnuplot wxt window. It >>> works nicely... except that I'm seeing a delay of up to 40 seconds >>> between clicking the button and the file-save dialog opening. >>> >>> This is on a lightly loaded system, with gnuplot launched via >>> gnuplot -persist<plotfile>. >> >> What operating system? > > Arch Linux. No other programs showing odd delays in response. I was thinking is might the Windows font issue again, but no... Searching, I'm seeing this comment about a program called "upower": https://wiki.archlinux.org/index.php/KDE#Dolphin_and_File_Dialogs_are_extremely_slow_to_start Is upower running on your system? Dan |
|
From: Allin C. <cot...@wf...> - 2014-11-15 18:35:50
|
On Sat, 15 Nov 2014, Daniel J Sebald wrote: > On 11/15/2014 11:55 AM, Allin Cottrell wrote: >> On Sat, 15 Nov 2014, Daniel J Sebald wrote: >> >>> On 11/15/2014 11:36 AM, Allin Cottrell wrote: >>>> I just tried out the file save button in the gnuplot wxt window. It >>>> works nicely... except that I'm seeing a delay of up to 40 seconds >>>> between clicking the button and the file-save dialog opening. >>>> >>>> This is on a lightly loaded system, with gnuplot launched via >>>> gnuplot -persist<plotfile>. >>> >>> What operating system? >> >> Arch Linux. No other programs showing odd delays in response. > > I was thinking is might the Windows font issue again, but no... > > Searching, I'm seeing this comment about a program called "upower": > > https://wiki.archlinux.org/index.php/KDE#Dolphin_and_File_Dialogs_are_extremely_slow_to_start > > Is upower running on your system? upowerd was running under systemd. I tried stopping and disabling upower but it didn't make an appreciable difference. When I press the save button it stays pressed and the wxt window becomes unresponsive -- the other buttons won't work and the window doesn't repaint itself if obscured. Then eventually the file dialog appears. Quite peculiar. Allin Cottrell |
|
From: Allin C. <cot...@wf...> - 2014-11-15 18:54:42
|
> On 11/15/2014 11:55 AM, Allin Cottrell wrote: >> On Sat, 15 Nov 2014, Daniel J Sebald wrote: >> >>> On 11/15/2014 11:36 AM, Allin Cottrell wrote: >>>> I just tried out the file save button in the gnuplot wxt window. It >>>> works nicely... except that I'm seeing a delay of up to 40 seconds >>>> between clicking the button and the file-save dialog opening. >>>> >>>> This is on a lightly loaded system, with gnuplot launched via >>>> gnuplot -persist<plotfile>. >>> >>> What operating system? >> >> Arch Linux. No other programs showing odd delays in response. Aha. No such problem if I run gnuplot interactively, load the plot file and display the plot. Then the Save button works instantly. The loooong delay just happens when gnuplot is run with -persist. Allin Cottrell |
|
From: sfeam <sf...@us...> - 2014-11-15 19:20:11
|
On Saturday, 15 November 2014 01:54:32 PM Allin Cottrell wrote: > > On 11/15/2014 11:55 AM, Allin Cottrell wrote: > >> On Sat, 15 Nov 2014, Daniel J Sebald wrote: > >> > >>> On 11/15/2014 11:36 AM, Allin Cottrell wrote: > >>>> I just tried out the file save button in the gnuplot wxt window. It > >>>> works nicely... except that I'm seeing a delay of up to 40 seconds > >>>> between clicking the button and the file-save dialog opening. > >>>> > >>>> This is on a lightly loaded system, with gnuplot launched via > >>>> gnuplot -persist<plotfile>. > >>> > >>> What operating system? > >> > >> Arch Linux. No other programs showing odd delays in response. > > Aha. No such problem if I run gnuplot interactively, load the plot > file and display the plot. Then the Save button works instantly. The > loooong delay just happens when gnuplot is run with -persist. In that case it might be informative to establish where the program is hung/delayed. Fire up gnuplot -persist, determinine its <pid>, then hit the problematic button. While it is in the hung state, from another terminal run $ gdb -p <pid> gdb> where to establish where the code is hung. Ethan |
|
From: Allin C. <cot...@wf...> - 2014-11-15 20:07:38
Attachments:
where.txt
|
On Sat, 15 Nov 2014, sfeam wrote: > On Saturday, 15 November 2014 01:54:32 PM Allin Cottrell wrote: >>> On 11/15/2014 11:55 AM, Allin Cottrell wrote: >>>> On Sat, 15 Nov 2014, Daniel J Sebald wrote: >>>> >>>>> On 11/15/2014 11:36 AM, Allin Cottrell wrote: >>>>>> I just tried out the file save button in the gnuplot wxt window. It >>>>>> works nicely... except that I'm seeing a delay of up to 40 seconds >>>>>> between clicking the button and the file-save dialog opening. >>>>>> >>>>>> This is on a lightly loaded system, with gnuplot launched via >>>>>> gnuplot -persist<plotfile>. >>>>> >>>>> What operating system? >>>> >>>> Arch Linux. No other programs showing odd delays in response. >> >> Aha. No such problem if I run gnuplot interactively, load the plot >> file and display the plot. Then the Save button works instantly. The >> loooong delay just happens when gnuplot is run with -persist. > > In that case it might be informative to establish where the > program is hung/delayed. > Fire up gnuplot -persist, determinine its <pid>, then hit > the problematic button. > While it is in the hung state, from another terminal run > $ gdb -p <pid> > gdb> where > > to establish where the code is hung. OK, I'm attaching the output from this. Allin Cottrell |
|
From: sfeam <sf...@us...> - 2014-11-15 20:40:09
|
On Saturday, 15 November 2014 03:07:27 PM Allin Cottrell wrote: > On Sat, 15 Nov 2014, sfeam wrote: > > > On Saturday, 15 November 2014 01:54:32 PM Allin Cottrell wrote: > >>> On 11/15/2014 11:55 AM, Allin Cottrell wrote: > >>>> On Sat, 15 Nov 2014, Daniel J Sebald wrote: > >>>> > >>>>> On 11/15/2014 11:36 AM, Allin Cottrell wrote: > >>>>>> I just tried out the file save button in the gnuplot wxt window. It > >>>>>> works nicely... except that I'm seeing a delay of up to 40 seconds > >>>>>> between clicking the button and the file-save dialog opening. > >>>>>> > >>>>>> This is on a lightly loaded system, with gnuplot launched via > >>>>>> gnuplot -persist<plotfile>. > >>>>> > >>>>> What operating system? > >>>> > >>>> Arch Linux. No other programs showing odd delays in response. > >> > >> Aha. No such problem if I run gnuplot interactively, load the plot > >> file and display the plot. Then the Save button works instantly. The > >> loooong delay just happens when gnuplot is run with -persist. > > > > In that case it might be informative to establish where the > > program is hung/delayed. > > Fire up gnuplot -persist, determinine its <pid>, then hit > > the problematic button. > > While it is in the hung state, from another terminal run > > $ gdb -p <pid> > > gdb> where > > > > to establish where the code is hung. > > OK, I'm attaching the output from this. > > Allin Cottrell I can reproduce this now, so at least I can investigate as I find time. No ideas at the moment, other than it may indicate an interlock failure in the gvfs/dbus library code. We could report that upstream to gtk, but I am afraid that we would then run into the problem that upstream development is focused on gtk3, while the problem is occurring in 2.8. I suppose we could disable the Export-to-File widget in persist mode, but that would be unfortunate. Ethan |
|
From: Daniel J S. <dan...@ie...> - 2014-11-15 22:51:01
|
On 11/15/2014 02:36 PM, sfeam wrote: > On Saturday, 15 November 2014 03:07:27 PM Allin Cottrell wrote: > >> On Sat, 15 Nov 2014, sfeam wrote: > >> > >> > On Saturday, 15 November 2014 01:54:32 PM Allin Cottrell wrote: > >> >>> On 11/15/2014 11:55 AM, Allin Cottrell wrote: > >> >>>> On Sat, 15 Nov 2014, Daniel J Sebald wrote: > >> >>>> > >> >>>>> On 11/15/2014 11:36 AM, Allin Cottrell wrote: > >> >>>>>> I just tried out the file save button in the gnuplot wxt window. It > >> >>>>>> works nicely... except that I'm seeing a delay of up to 40 seconds > >> >>>>>> between clicking the button and the file-save dialog opening. > >> >>>>>> > >> >>>>>> This is on a lightly loaded system, with gnuplot launched via > >> >>>>>> gnuplot -persist<plotfile>. > >> >>>>> > >> >>>>> What operating system? > >> >>>> > >> >>>> Arch Linux. No other programs showing odd delays in response. > >> >> > >> >> Aha. No such problem if I run gnuplot interactively, load the plot > >> >> file and display the plot. Then the Save button works instantly. The > >> >> loooong delay just happens when gnuplot is run with -persist. > >> > > >> > In that case it might be informative to establish where the > >> > program is hung/delayed. > >> > Fire up gnuplot -persist, determinine its <pid>, then hit > >> > the problematic button. > >> > While it is in the hung state, from another terminal run > >> > $ gdb -p <pid> > >> > gdb> where > >> > > >> > to establish where the code is hung. > >> > >> OK, I'm attaching the output from this. > >> > >> Allin Cottrell > > I can reproduce this now, so at least I can investigate as I find time. > > No ideas at the moment, other than it may indicate an interlock failure > > in the gvfs/dbus library code. We could report that upstream to gtk, > > but I am afraid that we would then run into the problem that upstream > > development is focused on gtk3, while the problem is occurring in 2.8. > > I suppose we could disable the Export-to-File widget in persist mode, > > but that would be unfortunate. I don't see this delay on my system (Gnome, GTK 2.0). If it still works, just slow, I'd say simply display some message "File dialog in persist mode may run slow", the first time the user attempts to save a file. But lets see if there is a bug there first. One thing that I notice is that in the WXT setting (the wrench) there is a check box for persist mode. If launching gnuplot with "-persist", that check box is not checked when I think it should be. If launching gnuplot without "-persist", does using the setting to change the "persist" checkbox also result in a slowdown when trying to save a file? Dan |
|
From: Allin C. <cot...@wf...> - 2014-11-16 00:56:14
|
On Sat, 15 Nov 2014, Daniel J Sebald wrote: > On 11/15/2014 02:36 PM, sfeam wrote: >> On Saturday, 15 November 2014 03:07:27 PM Allin Cottrell wrote: >> >> > On Sat, 15 Nov 2014, sfeam wrote: >> >> > > On Saturday, 15 November 2014 01:54:32 PM Allin Cottrell wrote: >> > > > > On 11/15/2014 11:55 AM, Allin Cottrell wrote: >> > > > > > On Sat, 15 Nov 2014, Daniel J Sebald wrote: >> > > > > > > On 11/15/2014 11:36 AM, Allin Cottrell wrote: >> > > > > > > > I just tried out the file save button in the gnuplot wxt >> > > > > > > > window. It >> > > > > > > > works nicely... except that I'm seeing a delay of up to 40 >> > > > > > > > seconds >> > > > > > > > between clicking the button and the file-save dialog >> > > > > > > > opening. >> > > > > > > > >> > > > > > > > This is on a lightly loaded system, with gnuplot >> > > > > > > > launched via gnuplot -persist<plotfile>. >> > > > > > > >> > > > > > > What operating system? >> >> > > > > > Arch Linux. No other programs showing odd delays in response. >> >> > > > Aha. No such problem if I run gnuplot interactively, load >> > > > the plot file and display the plot. Then the Save button >> > > > works instantly. The loooong delay just happens when >> > > > gnuplot is run with -persist. >> >> > > >> > > In that case it might be informative to establish where the >> > > program is hung/delayed. >> > > Fire up gnuplot -persist, determinine its <pid>, then hit >> > > the problematic button. >> > > While it is in the hung state, from another terminal run >> >> > > $ gdb -p <pid> >> >> > > gdb> where >> >> > > to establish where the code is hung. >> >> > OK, I'm attaching the output from this. >> > Allin Cottrell >> >> I can reproduce this now, so at least I can investigate as I >> find time. No ideas at the moment, other than it may indicate an >> interlock failure in the gvfs/dbus library code. We could report >> that upstream to gtk, but I am afraid that we would then run >> into the problem that upstream development is focused on gtk3, >> while the problem is occurring in 2.8. I suppose we could >> disable the Export-to-File widget in persist mode, but that >> would be unfortunate. > > I don't see this delay on my system (Gnome, GTK 2.0). > > If it still works, just slow, I'd say simply display some message "File > dialog in persist mode may run slow", the first time the user attempts to > save a file. But lets see if there is a bug there first. > > One thing that I notice is that in the WXT setting (the wrench) there is a > check box for persist mode. If launching gnuplot with "-persist", that check > box is not checked when I think it should be. > > If launching gnuplot without "-persist", does using the setting to change the > "persist" checkbox also result in a slowdown when trying to save a file? Here are my results (again, with today's CVS): 1) I do: gnuplot -persist <plotfile> The dialog opened by the wxt wrench icon shows the "persist" box checked; it always takes a long time for the Save dialog to appear. 2) I do: gnuplot (interactive) ; then 'load' plotfile a) If I click the wxt wrench icon, the dialog shows the "persist" box checked. If I click the Save icon while the calling gnuplot instance is still active, it always works instantly. (b) If I type 'quit' in the calling gnuplot instance, then try the Save icon in the wxt window, sometimes the Save dialog still comes up instantly and sometimes it takes ages. I haven't yet determined if there's any reliable predictor for the variant behaviors. Allin Cottrell |
|
From: sfeam <sf...@us...> - 2014-11-16 01:04:10
|
On Saturday, 15 November 2014 07:56:05 PM Allin Cottrell wrote: > Here are my results (again, with today's CVS): The behaviour you report is different in detail from what I see here. > 1) I do: gnuplot -persist <plotfile> > > The dialog opened by the wxt wrench icon shows the "persist" box > checked; it always takes a long time for the Save dialog to appear. I don't see any delay at all for this test case > 2) I do: gnuplot (interactive) ; then 'load' plotfile > > a) If I click the wxt wrench icon, the dialog shows the "persist" > box checked. If I click the Save icon while the calling gnuplot > instance is still active, it always works instantly. yes > (b) If I type 'quit' in the calling gnuplot instance, then try the > Save icon in the wxt window, sometimes the Save dialog still comes > up instantly and sometimes it takes ages. I haven't yet determined > if there's any reliable predictor for the variant behaviors. this is the case in which I see a delay. 'quit', or simply running gnuplot -persist file.gp, causes the main process to exit, leaving a subprocess to manage the persistent plot window. This is the state from whihc the toolbar button is slow to respond. Ethan > Allin Cottrell |
|
From: sfeam <sf...@us...> - 2014-11-16 01:12:10
|
On Saturday, 15 November 2014 05:02:52 PM sfeam wrote: > On Saturday, 15 November 2014 07:56:05 PM Allin Cottrell wrote: > > > Here are my results (again, with today's CVS): > > The behaviour you report is different in detail from what I see here. > > > > 1) I do: gnuplot -persist <plotfile> > > > > The dialog opened by the wxt wrench icon shows the "persist" box > > checked; it always takes a long time for the Save dialog to appear. > > I don't see any delay at all for this test case Oops. Sorry, I misunderstood. Yes I do see the delay for this case if the <plotfile> exits rather than issuing "pause mouse" or something of the sort. Ethan > > > > 2) I do: gnuplot (interactive) ; then 'load' plotfile > > > > a) If I click the wxt wrench icon, the dialog shows the "persist" > > box checked. If I click the Save icon while the calling gnuplot > > instance is still active, it always works instantly. > > yes > > > (b) If I type 'quit' in the calling gnuplot instance, then try the > > Save icon in the wxt window, sometimes the Save dialog still comes > > up instantly and sometimes it takes ages. I haven't yet determined > > if there's any reliable predictor for the variant behaviors. > > this is the case in which I see a delay. > 'quit', or simply running gnuplot -persist file.gp, > causes the main process to exit, leaving a subprocess > to manage the persistent plot window. This is the state > from whihc the toolbar button is slow to respond. > > Ethan > > > > Allin Cottrell > |
|
From: Daniel J S. <dan...@ie...> - 2014-11-16 01:18:50
|
On 11/15/2014 06:56 PM, Allin Cottrell wrote: > On Sat, 15 Nov 2014, Daniel J Sebald wrote: > >> On 11/15/2014 02:36 PM, sfeam wrote: >>> On Saturday, 15 November 2014 03:07:27 PM Allin Cottrell wrote: >>> >>> > On Sat, 15 Nov 2014, sfeam wrote: >>> >>> > > On Saturday, 15 November 2014 01:54:32 PM Allin Cottrell wrote: >>> > > > > On 11/15/2014 11:55 AM, Allin Cottrell wrote: >>> > > > > > On Sat, 15 Nov 2014, Daniel J Sebald wrote: >>> > > > > > > On 11/15/2014 11:36 AM, Allin Cottrell wrote: >>> > > > > > > > I just tried out the file save button in the gnuplot wxt >>> > > > > > > > window. It >>> > > > > > > > works nicely... except that I'm seeing a delay of up to >>> 40 > > > > > > > seconds >>> > > > > > > > between clicking the button and the file-save dialog > > >>> > > > > > opening. >>> > > > > > > > > > > > > > > This is on a lightly loaded system, with >>> gnuplot > > > > > > > launched via gnuplot -persist<plotfile>. >>> > > > > > > > > > > > > What operating system? >>> >>> > > > > > Arch Linux. No other programs showing odd delays in response. >>> >>> > > > Aha. No such problem if I run gnuplot interactively, load > > > >>> the plot file and display the plot. Then the Save button > > > works >>> instantly. The loooong delay just happens when > > > gnuplot is run >>> with -persist. >>> >>> > > > > In that case it might be informative to establish where the >>> > > program is hung/delayed. >>> > > Fire up gnuplot -persist, determinine its <pid>, then hit >>> > > the problematic button. >>> > > While it is in the hung state, from another terminal run >>> >>> > > $ gdb -p <pid> >>> >>> > > gdb> where >>> >>> > > to establish where the code is hung. >>> >>> > OK, I'm attaching the output from this. >>> > Allin Cottrell >>> >>> I can reproduce this now, so at least I can investigate as I >>> find time. No ideas at the moment, other than it may indicate an >>> interlock failure in the gvfs/dbus library code. We could report >>> that upstream to gtk, but I am afraid that we would then run >>> into the problem that upstream development is focused on gtk3, >>> while the problem is occurring in 2.8. I suppose we could >>> disable the Export-to-File widget in persist mode, but that >>> would be unfortunate. >> >> I don't see this delay on my system (Gnome, GTK 2.0). >> >> If it still works, just slow, I'd say simply display some message >> "File dialog in persist mode may run slow", the first time the user >> attempts to save a file. But lets see if there is a bug there first. >> >> One thing that I notice is that in the WXT setting (the wrench) there >> is a check box for persist mode. If launching gnuplot with "-persist", >> that check box is not checked when I think it should be. >> >> If launching gnuplot without "-persist", does using the setting to >> change the "persist" checkbox also result in a slowdown when trying to >> save a file? > > Here are my results (again, with today's CVS): > > 1) I do: gnuplot -persist <plotfile> > > The dialog opened by the wxt wrench icon shows the "persist" box > checked; it always takes a long time for the Save dialog to appear. > > 2) I do: gnuplot (interactive) ; then 'load' plotfile > > a) If I click the wxt wrench icon, the dialog shows the "persist" box > checked. If I click the Save icon while the calling gnuplot instance is > still active, it always works instantly. > > (b) If I type 'quit' in the calling gnuplot instance, then try the Save > icon in the wxt window, sometimes the Save dialog still comes up > instantly and sometimes it takes ages. I haven't yet determined if > there's any reliable predictor for the variant behaviors. OK. Ethan explained the "atexit" code to me, so I see how that is being called. Again, I can't make this hang on my system at all. I wonder if there might be a race condition here. wxt_atexit does a fork and Ethan confirmed on his system that is the last thing that is happening before a hang. However, the strange part of this wxt_atexit() code--if I'm understanding correctly--is that it appears to suspend the process with a signal interrupt and then restart the process in the child. What if that signal interrupt is done asynchronously in the O.S.? It could be that the fork happens/restart happens before the signal interrupt filters its way to the processes. When the hang happens on your system, is the their a daemon in the process list or is the gnuplot process active and consuming CPU? Dan |
|
From: sfeam <sf...@us...> - 2014-11-16 01:32:08
|
On Saturday, 15 November 2014 07:18:36 PM Daniel J Sebald wrote: > > When the hang happens on your system, is the their a daemon in the > process list or is the gnuplot process active and consuming CPU? I see the same as shown by the trace that Allin posted. The main process is gone, and the child process is in a poll() somewhere in a wxt library routine that bizarrely seems (from its name) to have something to do with audio. #0 0x00007fc0e243e30d in poll () from /lib64/libc.so.6 #1 0x00007fc0e6715434 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0 #2 0x00007fc0e671589a in g_main_loop_run () from /lib64/libglib-2.0.so.0 #3 0x00007fc0e53ed2e9 in initable_init () from /lib64/libgio-2.0.so.0 #4 0x00007fc0e537c54a in g_initable_new_valist () from /lib64/libgio-2.0.so.0 #5 0x00007fc0e537c62c in g_initable_new () from /lib64/libgio-2.0.so.0 #6 0x00007fc0d44e4bbd in gvfs_remote_volume_monitor_proxy_new_for_bus_sync () from /usr/lib64/gio/modules/libgioremote-volume-monitor.so Ethan |
|
From: Allin C. <cot...@wf...> - 2014-11-16 14:10:50
|
On Sat, 15 Nov 2014, sfeam wrote: > On Saturday, 15 November 2014 07:18:36 PM Daniel J Sebald wrote: > >> >> When the hang happens on your system, is the their a daemon in the >> process list or is the gnuplot process active and consuming CPU? > > I see the same as shown by the trace that Allin posted. > The main process is gone, and the child process is in a > poll() somewhere in a wxt library routine that bizarrely > seems (from its name) to have something to do with audio. I think that in this context "volume" refers to file systems, not decibels. It would make sense that opening a file-save dialog might trigger some sort of scan of volumes in that sense. Allin Cottrell > > #0 0x00007fc0e243e30d in poll () from /lib64/libc.so.6 > #1 0x00007fc0e6715434 in g_main_context_iterate.isra.24 () from /lib64/libglib-2.0.so.0 > #2 0x00007fc0e671589a in g_main_loop_run () from /lib64/libglib-2.0.so.0 > #3 0x00007fc0e53ed2e9 in initable_init () from /lib64/libgio-2.0.so.0 > #4 0x00007fc0e537c54a in g_initable_new_valist () from /lib64/libgio-2.0.so.0 > #5 0x00007fc0e537c62c in g_initable_new () from /lib64/libgio-2.0.so.0 > #6 0x00007fc0d44e4bbd in gvfs_remote_volume_monitor_proxy_new_for_bus_sync () > from /usr/lib64/gio/modules/libgioremote-volume-monitor.so > > Ethan |
|
From: Daniel J S. <dan...@ie...> - 2014-11-16 02:32:51
|
On 11/15/2014 07:31 PM, sfeam wrote:
> On Saturday, 15 November 2014 07:18:36 PM Daniel J Sebald wrote:
>
>>
>
>> When the hang happens on your system, is the their a daemon in the
>
>> process list or is the gnuplot process active and consuming CPU?
I meant "zombie", not daemon.
> I see the same as shown by the trace that Allin posted.
>
> The main process is gone, and the child process is in a
>
> poll() somewhere in a wxt library routine that bizarrely
>
> seems (from its name) to have something to do with audio.
>
> #0 0x00007fc0e243e30d in poll () from /lib64/libc.so.6
>
> #1 0x00007fc0e6715434 in g_main_context_iterate.isra.24 () from
> /lib64/libglib-2.0.so.0
>
> #2 0x00007fc0e671589a in g_main_loop_run () from /lib64/libglib-2.0.so.0
>
> #3 0x00007fc0e53ed2e9 in initable_init () from /lib64/libgio-2.0.so.0
>
> #4 0x00007fc0e537c54a in g_initable_new_valist () from
> /lib64/libgio-2.0.so.0
>
> #5 0x00007fc0e537c62c in g_initable_new () from /lib64/libgio-2.0.so.0
>
> #6 0x00007fc0d44e4bbd in
> gvfs_remote_volume_monitor_proxy_new_for_bus_sync ()
>
> from /usr/lib64/gio/modules/libgioremote-volume-monitor.so
>
> Ethan
Yes, strange.
My guess would be that stopping the GUI thread with an event and then
restarting it is the source of the problem, or something within the
interrupt handler code (but so convoluted to follow). You could try
this simple test and see if the file dialog button always functions or
not when leaving the main thread be--remove the lines of code as below
with comments:
+++++
Index: src/wxterminal/wxt_gui.cpp
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/src/wxterminal/wxt_gui.cpp,v
retrieving revision 1.128.2.6
diff -u -r1.128.2.6 wxt_gui.cpp
--- src/wxterminal/wxt_gui.cpp 12 Nov 2014 05:20:18 -0000 1.128.2.6
+++ src/wxterminal/wxt_gui.cpp 16 Nov 2014 02:21:55 -0000
@@ -3923,7 +3923,7 @@
wxCommandEvent event(wxExitLoopEvent);
wxt_MutexGuiEnter();
- dynamic_cast<wxtApp*>(wxTheApp)->SendEvent( event );
+// dynamic_cast<wxtApp*>(wxTheApp)->SendEvent( event );
wxt_MutexGuiLeave();
/* handle eventual interrupt, and restore original sigint handler */
@@ -4018,7 +4018,7 @@
freopen("/dev/null","w",stderr);
/* (re)start gui loop */
- wxTheApp->OnRun();
+// wxTheApp->OnRun();
FPRINTF((stderr,"child process: event loop exited\n"));
# ifdef HAVE_WORKING_FORK
+++++
The gnuplot command line process will remain suspended and
uninterruptable, but the idea is to test the GUI behavior.
There must be some way of doing this without having to stop/restart a
thread in the process.
Dan
|
|
From: sfeam <sf...@us...> - 2014-11-16 04:02:00
|
Here's a fun one. I don't know what it means exactly, but it seems to offer a hint that suitable initialization might prevent this problem: ./gnuplot -persist -e 'set term wxt ; plot sinc(x) ; pause 10' 1) If you let the 10 seconds elapse so that the main thread exits, then clicking the Export-to-File button will hang as described. 2) But if you click the button _during_ the 10 second window, everything is fine. That by itself is no surprise, but all subsequent clicks on that same widget work immediately even though the 10 seconds window is long over. So clicking on it once while the main thread is still active "primes the pump". If we knew the critical piece of this, we could maybe invoke it on program entry, or when the plot window first appears, and that would make subsequent Export operations in -persist mode work smoothly. Ethan |
|
From: sfeam <sf...@us...> - 2014-11-16 06:40:11
|
This bug tracker item from Debian seems relevant: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=577470 The trace there is nearly the same as we are seeing. I don't see a true resolution to the problem in that thread. Apparently it involved a version mismatch in gnome/dbus/gvfs components, but all the versions mentioned are much older than I have now. Ethan |
|
From: sfeam <sf...@us...> - 2014-11-16 04:12:08
|
On Saturday, 15 November 2014 08:32:38 PM Daniel J Sebald wrote: > I meant "zombie", not daemon. I don't see a zombie. The original process really does exit. > There must be some way of doing this without having to stop/restart a > thread in the process. The problem does not depend stop/start of a thread. It acts the same even if gnuplot is built in single-threaded mode. The exit+persist procedure is to fork(), leaving a parent and a child. The parent calls atexit() and exits. The child is supposed to maintain the plot window. Both the parent and child can be a single thread. I don't say that this is necessarily the only possible procedure or the best procedure, but that's the way it currently works. Ethan |
|
From: Daniel J S. <dan...@ie...> - 2014-11-16 08:09:19
|
On 11/15/2014 10:09 PM, sfeam wrote:
> On Saturday, 15 November 2014 08:32:38 PM Daniel J Sebald wrote:
>
>> I meant "zombie", not daemon.
>
> I don't see a zombie. The original process really does exit.
>
>> There must be some way of doing this without having to stop/restart a
>
>> thread in the process.
>
> The problem does not depend stop/start of a thread.
>
> It acts the same even if gnuplot is built in single-threaded mode.
>
> The exit+persist procedure is to fork(), leaving a parent and a child.
>
> The parent calls atexit() and exits. The child is supposed
>
> to maintain the plot window. Both the parent and child can
>
> be a single thread. I don't say that this is necessarily the
>
> only possible procedure or the best procedure, but that's the
>
> way it currently works.
The fork idea is OK. (Well, so-so. Remember there's the limitation of
WXT not being an outboard driver.)
I'm wondering about this hunk of code though:
/* (re)start gui loop */
wxTheApp->OnRun();
If I'm understanding correctly, there is some sort of custom event
handling whereby gnuplot manages input events and then shuffles them off
to wxWidgets with the ::SendEvent( wxEvent &event) function. I.e.,
/* wrapper for AddPendingEvent or ProcessEvent */
void wxtApp::SendEvent( wxEvent &event)
{
#ifdef WXT_MULTITHREADED
AddPendingEvent(event);
#else /* !WXT_MULTITHREADED */
ProcessEvent(event);
#endif /* !WXT_MULTITHREADED */
}
Generally, gnuplot is not using wxWidgets event loop (because otherwise
it would be unable to do anything). But then, when gnuplot exits with
persist, it passes event loop processing off to wxWidgets using
wxTheApp->OnRun().
However, that means that even though the wxWidgets objects function
properly (because events are handled by OnRun()) gnuplot can no longer
manage events or in fact do anything. I just confirmed that is the
case. The WXT plot window left behind by persist is basically frozen.
Try right mouse click, or scaling the window and the plot is fragmented.
What's more, the wxWidget events of OnRun() no longer work at that
point either.
This wxApp->OnRun() is sort of a trick to make the WXT terminal seem
persistent, but it isn't persistent in the sense that Qt terminal is, or
X11 terminal is. Gnuplot child process is still running and everything
still available (it's just no longer at the command line). Is there
some way that the core gnuplot event handling can be called instead of
calling wxApp->OnRun()? The right way is the outboard setup, but in
lieu of that might as well make the WXT terminal fully functional when
persistent.
Dan
|
|
From: Allin C. <cot...@wf...> - 2014-11-16 14:28:50
|
On Sun, 16 Nov 2014, Daniel J Sebald wrote: > Generally, gnuplot is not using wxWidgets event loop (because otherwise it > would be unable to do anything). But then, when gnuplot exits with persist, > it passes event loop processing off to wxWidgets using wxTheApp->OnRun(). > > However, that means that even though the wxWidgets objects function properly > (because events are handled by OnRun()) gnuplot can no longer manage events > or in fact do anything. I just confirmed that is the case. The WXT plot > window left behind by persist is basically frozen. Try right mouse click, or > scaling the window and the plot is fragmented. [...] I don't find that to be the case at all. The wxt window left open by "gnuplot -persist plotfile" works fine, in general: it resizes correctly, responds to right-mouse as expected, and all the menu buttons work apart from the delay in the case of Save. The same goes for the case where gnuplot is started interactively, a wxt plot is displayed, then I do "quit" at the gnuplot CLI: the wxt window works fine apart from Save. Re. the file dialog I suspect there's some sort of required gvfs/gio initialization that is not being inherited (fully) by the child on fork(). Allin Cottrell |
|
From: Daniel J S. <dan...@ie...> - 2014-11-16 09:24:04
|
On 11/16/2014 01:31 AM, Daniel J Sebald wrote:
> On 11/15/2014 10:09 PM, sfeam wrote:
>> On Saturday, 15 November 2014 08:32:38 PM Daniel J Sebald wrote:
>>
>>> I meant "zombie", not daemon.
>>
>> I don't see a zombie. The original process really does exit.
>>
>>> There must be some way of doing this without having to stop/restart a
>>
>>> thread in the process.
>>
>> The problem does not depend stop/start of a thread.
>>
>> It acts the same even if gnuplot is built in single-threaded mode.
>>
>> The exit+persist procedure is to fork(), leaving a parent and a child.
>>
>> The parent calls atexit() and exits. The child is supposed
>>
>> to maintain the plot window. Both the parent and child can
>>
>> be a single thread. I don't say that this is necessarily the
>>
>> only possible procedure or the best procedure, but that's the
>>
>> way it currently works.
>
> The fork idea is OK. (Well, so-so. Remember there's the limitation of
> WXT not being an outboard driver.)
>
> I'm wondering about this hunk of code though:
>
> /* (re)start gui loop */
> wxTheApp->OnRun();
>
> If I'm understanding correctly, there is some sort of custom event
> handling whereby gnuplot manages input events and then shuffles them off
> to wxWidgets with the ::SendEvent( wxEvent&event) function. I.e.,
>
> /* wrapper for AddPendingEvent or ProcessEvent */
> void wxtApp::SendEvent( wxEvent&event)
> {
> #ifdef WXT_MULTITHREADED
> AddPendingEvent(event);
> #else /* !WXT_MULTITHREADED */
> ProcessEvent(event);
> #endif /* !WXT_MULTITHREADED */
> }
>
> Generally, gnuplot is not using wxWidgets event loop (because otherwise
> it would be unable to do anything). But then, when gnuplot exits with
> persist, it passes event loop processing off to wxWidgets using
> wxTheApp->OnRun().
OK, I was mistaken on that. There's another ->OnRun() in the code.
This one as part of wxtThread::Entry():
/* 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();
Maybe that's where the problem is. The wxt_MutexGuiLeave() routine
looks like:
void wxt_MutexGuiLeave()
{
FPRINTF2((stderr,"unlocking gui mutex\n"));
#ifdef WXT_MULTITHREADED
if (!wxt_handling_persist)
wxMutexGuiLeave();
#endif /* WXT_MULTITHREADED */
}
I think the idea is that if the window is persistent and exiting, then
do not leave go of the Mutex, i.e., GUI access from non-main-thread.
However, I've just done some fprintf's on my system to find that this
may not happen in the right order. The "wxt_handling_persist" variable
is set to "true" inside wxt_atexit(). However, what I'm seeing is that
/* gui loop */
wxTheApp->OnRun();
inside wxtThread::Entry() [repeat the one inside wxtThread::Entry()]
completes prior to wxt_atexit() call. So "wxt_handling_persist" isn't
set when OnRun() initially exits. I'm guessing that is what the
original intent of this variable was, otherwise it doesn't seem to have
any purpose inside of wxt_atexit().
That does seem like it could be an issue here, i.e., the persistent WXT
terminal window is trying to access widgets for which it doesn't have a
lock on the GUI resources.
Dan
|
|
From: Allin C. <cot...@wf...> - 2014-11-16 19:12:37
|
Here's another funny. If I do sudo gnuplot -persist plotfile there's no delay in opening the file dialog via the Save button in the wxt plot window. Cf. http://ubuntuforums.org/showthread.php?t=1092467 -- Allin Cottrell Department of Economics Wake Forest University, NC |
|
From: sfeam <sf...@us...> - 2014-11-16 19:39:07
|
On Sunday, 16 November 2014 02:12:28 PM Allin Cottrell wrote: > Here's another funny. If I do > > sudo gnuplot -persist plotfile > > there's no delay in opening the file dialog via the Save button in the > wxt plot window. Cf. http://ubuntuforums.org/showthread.php?t=1092467 This seems to be a bug in gvfs, which claims to be "a Virtual File System library based on gio and Glib". gvfs is installed on my machine, but does not seem to be needed by anything. If I remove every package with "*gvfs*" in its name: urpme gvfs gvfs-archive gvfs-fuse gvfs-gphoto2 gvfs-iphone gvfs-mtp gvfs-smb lib64gvfscommon0 I get no errors or warnings about dependencies, and the gnuplot + wxt + Export problem goes away. Dan - does your machine have gvfs? If so, what version? Ethan |
|
From: Daniel J S. <dan...@ie...> - 2014-11-16 20:00:26
|
On 11/16/2014 01:38 PM, sfeam wrote: > On Sunday, 16 November 2014 02:12:28 PM Allin Cottrell wrote: > >> Here's another funny. If I do > >> > >> sudo gnuplot -persist plotfile > >> > >> there's no delay in opening the file dialog via the Save button in the > >> wxt plot window. Cf. http://ubuntuforums.org/showthread.php?t=1092467 > > This seems to be a bug in gvfs, which claims to be > > "a Virtual File System library based on gio and Glib". > > gvfs is installed on my machine, but does not seem to be needed by anything. > > If I remove every package with "*gvfs*" in its name: > > urpme gvfs gvfs-archive gvfs-fuse gvfs-gphoto2 gvfs-iphone gvfs-mtp > gvfs-smb lib64gvfscommon0 > > I get no errors or warnings about dependencies, and the > > gnuplot + wxt + Export problem goes away. > > Dan - does your machine have gvfs? If so, what version? Yes. Version 1.6.6-1. These processes are all resident, but sleeping: 1754 ? 00:00:00 gvfsd 1763 ? 00:00:00 gvfs-fuse-daemo 1775 ? 00:00:00 gvfs-gdu-volume 1785 ? 00:00:00 gvfs-gphoto2-vo 1787 ? 00:00:00 gvfs-afc-volume 2007 ? 00:00:00 gvfsd-trash 2064 ? 00:00:00 gvfsd-metadata 2066 ? 00:00:00 gvfsd-burn Dan |
|
From: sfeam <sf...@us...> - 2014-11-16 20:13:55
|
On Sunday, 16 November 2014 02:00:06 PM Daniel J Sebald wrote: > On 11/16/2014 01:38 PM, sfeam wrote: > > On Sunday, 16 November 2014 02:12:28 PM Allin Cottrell wrote: > > > >> Here's another funny. If I do > > > >> > > > >> sudo gnuplot -persist plotfile > > > >> > > > >> there's no delay in opening the file dialog via the Save button in the > > > >> wxt plot window. Cf. http://ubuntuforums.org/showthread.php?t=1092467 > > > > This seems to be a bug in gvfs, which claims to be > > > > "a Virtual File System library based on gio and Glib". > > > > gvfs is installed on my machine, but does not seem to be needed by anything. > > > > If I remove every package with "*gvfs*" in its name: > > > > urpme gvfs gvfs-archive gvfs-fuse gvfs-gphoto2 gvfs-iphone gvfs-mtp > > gvfs-smb lib64gvfscommon0 > > > > I get no errors or warnings about dependencies, and the > > > > gnuplot + wxt + Export problem goes away. > > > > Dan - does your machine have gvfs? If so, what version? > > Yes. Version 1.6.6-1. These processes are all resident, but sleeping: > > Dan Huh. That's much older. The version I deleted was gvfs-1.18.3-1.mga4.x86_64 I wonder if there's a reliable way to have the program say "I don't want any gvfs, thanks" rather than disabling it for the entire system? Then again, maybe if I were running a Gnome desktop gvfs would actually work. So far as I can tell the whole gvfs infrastructure is not relevant to KDE. Ethan |
