Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2015-11-29 21:45:07
|
Hi, I just ran current cvs gnuplot while su as another user. This meant that gnuplot could not find the DISPLAY to connect to. However this failure was not correctly ( at all ) trapped and I needed to ^C out to get back to the gnupplot prompt. I would expect it to drop out instantly , preferably with an error message. gnuplot> plot [-pi:pi] sin(x) QXcbConnection: Could not connect to display q quit ^C gnuplot> Presumably there are other reasons qt may fail to open the plot window and this rather unusual situation probably highlights poor error trapping here. Regards, Peter. |
|
From: Daniel J S. <dan...@ie...> - 2015-11-30 04:01:52
|
On 11/29/2015 03:38 PM, pl...@pi... wrote: > Hi, > > I just ran current cvs gnuplot while su as another user. This meant that > gnuplot could not find the DISPLAY to connect to. However this failure > was not correctly ( at all ) trapped and I needed to ^C out to get back > to the gnupplot prompt. > > I would expect it to drop out instantly , preferably with an error message. > > > gnuplot> plot [-pi:pi] sin(x) > QXcbConnection: Could not connect to display > q > > quit > ^C > gnuplot> > > > Presumably there are other reasons qt may fail to open the plot window > and this rather unusual situation probably highlights poor error > trapping here. > > Regards, Peter. Please create a bug report on the bug tracker with this message if you haven't done so already. The Qt terminal is pretty good, but I'm sure there are some things not done just right. Be sure to repeat what you are doing with something like the WXT terminal which also uses the graphics framework, and check if that hangs as well. Thanks. If you want to run under the root, there is "su -l" option. Dan |
|
From: <pl...@pi...> - 2015-11-30 08:10:04
|
On 30/11/15 04:01, Daniel J Sebald wrote: > On 11/29/2015 03:38 PM, pl...@pi... wrote: >> Hi, >> >> I just ran current cvs gnuplot while su as another user. This meant that >> gnuplot could not find the DISPLAY to connect to. However this failure >> was not correctly ( at all ) trapped and I needed to ^C out to get back >> to the gnupplot prompt. >> >> I would expect it to drop out instantly , preferably with an error >> message. >> >> >> gnuplot> plot [-pi:pi] sin(x) >> QXcbConnection: Could not connect to display >> q >> >> quit >> ^C >> gnuplot> >> >> >> Presumably there are other reasons qt may fail to open the plot window >> and this rather unusual situation probably highlights poor error >> trapping here. >> >> Regards, Peter. > > Please create a bug report on the bug tracker with this message if you > haven't done so already. The Qt terminal is pretty good, but I'm sure > there are some things not done just right. Be sure to repeat what you > are doing with something like the WXT terminal which also uses the > graphics framework, and check if that hangs as well. Thanks. > > If you want to run under the root, there is "su -l" option. > > Dan > Thanks Dan, I tired wxt and threw a seg. fault . However, after rebooting both terminals seem to act correctly. There may have been some libraries still in memory from before a routine update. I probably had not power cycled the machine for about a week and there had been updates. I just tried to repeat this to get more detail and it seems to be trapped correctly: gnuplot> plot [-pi:pi] sin(x) libGL error: failed to open drm device: Permission denied libGL error: failed to load driver: nouveau gnuplot> Unless I see something similar again, I would conclude it was a one-off error, probably due to mixed library modules lurking in memory. Sorry for the noise. Peter. |
|
From: Daniel J S. <dan...@ie...> - 2015-11-30 08:30:59
|
On 11/30/2015 02:09 AM, pl...@pi... wrote: > On 30/11/15 04:01, Daniel J Sebald wrote: >> On 11/29/2015 03:38 PM, pl...@pi... wrote: >>> Hi, >>> >>> I just ran current cvs gnuplot while su as another user. This meant that >>> gnuplot could not find the DISPLAY to connect to. However this failure >>> was not correctly ( at all ) trapped and I needed to ^C out to get back >>> to the gnupplot prompt. >>> >>> I would expect it to drop out instantly , preferably with an error >>> message. >>> >>> >>> gnuplot> plot [-pi:pi] sin(x) >>> QXcbConnection: Could not connect to display >>> q >>> >>> quit >>> ^C >>> gnuplot> >>> >>> >>> Presumably there are other reasons qt may fail to open the plot window >>> and this rather unusual situation probably highlights poor error >>> trapping here. >>> >>> Regards, Peter. >> >> Please create a bug report on the bug tracker with this message if you >> haven't done so already. The Qt terminal is pretty good, but I'm sure >> there are some things not done just right. Be sure to repeat what you >> are doing with something like the WXT terminal which also uses the >> graphics framework, and check if that hangs as well. Thanks. >> >> If you want to run under the root, there is "su -l" option. >> >> Dan >> > > Thanks Dan, > > I tired wxt and threw a seg. fault . However, after rebooting both > terminals seem to act correctly. There may have been some libraries > still in memory from before a routine update. I probably had not power > cycled the machine for about a week and there had been updates. > > I just tried to repeat this to get more detail and it seems to be > trapped correctly: > > > gnuplot> plot [-pi:pi] sin(x) > libGL error: failed to open drm device: Permission denied > libGL error: failed to load driver: nouveau > gnuplot> > > > Unless I see something similar again, I would conclude it was a one-off > error, probably due to mixed library modules lurking in memory. > > Sorry for the noise. > > Peter. I don't know what to conclude from that. The first error >>> QXcbConnection: Could not connect to display looks like something that would happen if the gnome (or similar) framework is not initialized, as the root has by default. On the other hand, the second case looks like libGL errors. Nouveau is an experimental libGL driver intended for Nvidia cards. I think I'm able to replicate what you originally saw, just by running from root without the -l option. The error I get is: Terminal type set to 'qt' gnuplot> plot x ** GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL) exit ^C gnuplot> exit Dan |
|
From: <pl...@pi...> - 2015-11-30 15:03:15
|
On 30/11/15 08:30, Daniel J Sebald wrote: > On 11/30/2015 02:09 AM, pl...@pi... wrote: >> On 30/11/15 04:01, Daniel J Sebald wrote: >>> On 11/29/2015 03:38 PM, pl...@pi... wrote: >>>> Hi, >>>> >>>> I just ran current cvs gnuplot while su as another user. This meant >>>> that >>>> gnuplot could not find the DISPLAY to connect to. However this failure >>>> was not correctly ( at all ) trapped and I needed to ^C out to get back >>>> to the gnupplot prompt. >>>> >>>> I would expect it to drop out instantly , preferably with an error >>>> message. >>>> >>>> >>>> gnuplot> plot [-pi:pi] sin(x) >>>> QXcbConnection: Could not connect to display >>>> q >>>> >>>> quit >>>> ^C >>>> gnuplot> >>>> >>>> >>>> Presumably there are other reasons qt may fail to open the plot window >>>> and this rather unusual situation probably highlights poor error >>>> trapping here. >>>> >>>> Regards, Peter. >>> >>> Please create a bug report on the bug tracker with this message if you >>> haven't done so already. The Qt terminal is pretty good, but I'm sure >>> there are some things not done just right. Be sure to repeat what you >>> are doing with something like the WXT terminal which also uses the >>> graphics framework, and check if that hangs as well. Thanks. >>> >>> If you want to run under the root, there is "su -l" option. >>> >>> Dan >>> >> >> Thanks Dan, >> >> I tired wxt and threw a seg. fault . However, after rebooting both >> terminals seem to act correctly. There may have been some libraries >> still in memory from before a routine update. I probably had not power >> cycled the machine for about a week and there had been updates. >> >> I just tried to repeat this to get more detail and it seems to be >> trapped correctly: >> >> >> gnuplot> plot [-pi:pi] sin(x) >> libGL error: failed to open drm device: Permission denied >> libGL error: failed to load driver: nouveau >> gnuplot> >> >> >> Unless I see something similar again, I would conclude it was a one-off >> error, probably due to mixed library modules lurking in memory. >> >> Sorry for the noise. >> >> Peter. > > I don't know what to conclude from that. The first error > >>>> QXcbConnection: Could not connect to display > > looks like something that would happen if the gnome (or similar) > framework is not initialized, as the root has by default. On the other > hand, the second case looks like libGL errors. Nouveau is an > experimental libGL driver intended for Nvidia cards. > > I think I'm able to replicate what you originally saw, just by running > from root without the -l option. The error I get is: > > Terminal type set to 'qt' > gnuplot> plot x > ** > GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: > (connection->initialization_error == NULL) > > exit > ^C > gnuplot> exit > > Dan > Just to clarify my original error , I was su into a normal user account . Gnuplot works correctly for that user account when logged in directly. Whatever happened before, both qt and wxt are functional in the same context now. I switch user with : su - username I think the error is reproduced by $DISPLAY being undefined. This is a new installation where I have been doing some configuration changes so it may well have been that for some reason the user account was not properly configured when I initially hit this problem. I think your 'root without i ' test is also creating a context where $DISPLAY is undefined. Having determined that, it still comes back to some poor error trapping that maybe ought to be reviewed. The libGL errors I'm now getting from qt are a bit odd because both drm and nouveau are loaded already. The nouveau driver has been default on Fedora for quite a while, it is not really that 'experimental' any more. modprobe nouveau returns zero ( no error ) so it's odd , firstly that something is trying load it at this stage ( Xwindow server running ) and secondly that it somehow reports an error when trying. Again this may be an invitation to check over the error trapping. Thanks for taking an interest. Peter. |
