I have the current dev configured --with-qt and built with libqt4 (4:4.8.1-0ubuntu4.4) on Ubuntu 12.04.
When I plot something and start left-clicking around in the plot, the qt terminal closes and shows the error message below in the terminal. This happens sometimes after 2 clicks, sometimes only after >10.
Terminal type set to 'qt'
gnuplot> plot sin(x)
gnuplot> ############### WRONG readEvent 758197814 69
Qt terminal communication error: select() error 9 Bad file descriptorgnuplot> plot sin(x)
Could not connect gnuplot_qt "" . Starting a new one
gnuplot> ############### WRONG readEvent 758132277 69
Qt terminal communication error: select() error 9 Bad file descriptorgnuplot>
A build of gnuplot 4.6.4 with qt on the same system does not show this bug.
The usual cause for that error message is a mismatch between the version of gnuplot itself and the version of the gnuplot_qt outboard driver. If you had a previous version of gnuplot installed and now you've just built but not installed a new one, it could be failing because it still tries to use the newly built gnuplot but the old gnuplot_qt. Try setting environmental variable GNUPLOT_DRIVER_DIR to the directly containing your newly built version.
Thanks for your quick response.
I indeed ran gnuplot from the build tree. But now I uninstalled all existing versions of gnuplot, manually removed all /usr/local/libexec/gnuplot/*/gnuplot_qt binaries, installed a newly built version, and the problem persists. I set GNUPLOT_DRIVER_DIR=/usr/local/libexec/gnuplot/4.7 (which was created after installation) but that did not resolve my problem. Neither when I set the variable to my build directory.
I tried setting the variable deliberately to the binary from a 4.6.4 build, in that case a similar error happens immediately when I try to plot something.
Yes, I can now confirm the problem.
I don't know what's going on, but it appears to have been introduced with the dynamic initialization of the qt terminal data structures.
If we can't figure out what the problem is, I may have to revert that.
It turns out the regression came in the patch subsequent to the dynamic initialization patch. I've reverted the code to essentially what it was before that. I think that it is still possible to trigger this error, but it is far harder to hit than in the now-reverted code.
Thanks, I tested it briefly, the error doesn't occur as easily any more.