> On Jul 29, 2015, at 7:56 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > > Hi Jim: > > I have just discovered the regression mentioned by the subject line. > > My apologies for not spotting this issue earlier in the release cycle. > I guess I did all sorts of spot checking after your multiple keypress > changes to make sure the cairo device driver built and ran without > issues, but I did not test all cairo capabilities like a simple build > of the test_interactive target (which caught this problem now) would > have done at the time. >
The interesting thing is that at least one of the sources for the error message is in the plD_init_xcairo() function. The XInternAtom() call generates some of the messages. Furthermore, the XCloseDisplay() in plD_tidy_xcairo() generates the error message. I thought it might be due to a synchronization issue with the X server, so I put an XSync() call to make sure everything was processed in the event queue. Unfortunately, the error “migrated” to the XSync() call. I then enabled synchronization via XSynchronize() (the sledgehammer approach). That eliminated some of the runtime error messages. I think this bug is a latent problem that has not cropped up earlier. I am not quite sure of the root cause, but I don’t think 78344df is the cause, rather it exposed the problem. I am not familiar enough with the external drawable functionality and, unfortunately, I don’t have time to dig into right now. If you insert "XSynchronize( aStream->Display, TRUE );” some where after the XOpenDisplay() call, I think that will fix the bug for this release. I will revisit the issue after the weekend. > Here is a quick summary of the relevant range of commits that I > discovered via git bisect: > > software@raven> git log --oneline 78344dfc901e^^^^..78344dfc901e > 78344df Corrections to the cairo.c file to fix compilation error > 009fa6b Updated the wingcc driver to reflect the changes for the keypress bug > 5867959 Fix to the multiple keypress bug on page advance > 602bb49 Driver documentation: use correct names of files that need updating > for new device driver > > If I build the test_extXdrawable target for 602bb49, all is well. If > I try that for 5867959 or 009fa6b there are cairo build errors that > are fixed in 78344df. Building test_extXdrawable for > 78344df (or any later commit including master tip) gives the following > run-time error: > > [100%] Built target test_cairo_dyndriver > The program 'extXdrawable_demo' received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadWindow (invalid Window parameter)'. > (Details: serial 178 error_code 3 request_code 2 minor_code 0) > (Note to programmers: normally, X errors are reported asynchronously; > that is, you will receive the error a while after causing it. > To debug your program, run it with the --sync command line > option to change this behavior. You can then get a meaningful > backtrace from your debugger if you break on the gdk_x_error() function.) > make[3]: *** [examples/CMakeFiles/test_extXdrawable] Error 1 > make[2]: *** [examples/CMakeFiles/test_extXdrawable.dir/all] Error 2 > make[1]: *** [examples/CMakeFiles/test_extXdrawable.dir/rule] Error 2 > make: *** [test_extXdrawable] Error 2 > > Note for this commit the test_extcairo target builds without issues > and the output examples/ext-cairo-test.ps from that example has the > expected plot box. > > Also > > make cairo > make x01c > examples/c/x01c -dev xcairo > > works without any run-time issues for this commit. > > So the conclusion is your change only introduced some issue for the > external X drawable cairo example examples/c/extXdrawable_demo.c and nothing > else. So I am hoping only a small change to that demo will fix the > issue rather than having to do some further core change to PLplot. > > I view this regression as release critical since I don't want to make > a release where the external X drawable capability of the cairo device > driver might be compromised. Therefore, I would appreciate your > solution for this issue as soon as possible, please, since the current > plan is to release on Saturday. > > If you are having trouble replicating this issue on your Mac OS X box, > let me know, and I would be happy to run any test on my Linux box that > might help you figure this out. > > Alan > __________________________ > Alan W. Irwin > > Astronomical research affiliation with Department of Physics and Astronomy, > University of Victoria (astrowww.phys.uvic.ca). > > Programming affiliations with the FreeEOS equation-of-state > implementation for stellar interiors (freeeos.sf.net); the Time > Ephemerides project (timeephem.sf.net); PLplot scientific plotting > software package (plplot.sf.net); the libLASi project > (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); > and the Linux Brochure Project (lbproject.sf.net). > __________________________ > > Linux-powered Science > __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
