> On Jul 30, 2015, at 6:36 AM, Jim Dishaw <j...@dishaw.org> wrote: > > > > > >>> On Jul 30, 2015, at 3:21 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> >>> wrote: >>> >>> On 2015-07-30 01:08-0400 Jim Dishaw wrote: >>> >>> >>>> 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. >> >> I inserted the following change (which is what I think you meant >> by the above suggestion, but please confirm that. >> >> --- a/drivers/cairo.c >> +++ b/drivers/cairo.c >> @@ -1995,6 +1995,7 @@ void plD_init_xcairo( PLStream *pls ) >> plexit( "Failed to open X Windows display\n" ); >> // some sort of error here >> } >> + XSynchronize( aStream->XDisplay, TRUE ); >> XScreen = DefaultScreen( aStream->XDisplay ); >> rootWindow = RootWindow( aStream->XDisplay, XScreen ); >> If that is what you had in mind, that change does not seem to affect the >> ordinary use of xcairo or >> the results from building the test_extcairo target. However, building >> the test_extXdrawable target still generates the same error message, >> i.e., >> >> Scanning dependencies of target test_extXdrawable >> 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 > > That patch fixes the problem when PLPlot is creating the window. Try adding > one more inside the "then" case at line 1983.
Oops, that won't work. I think the only solution right now is to roll back the patch. > >> Jim, since the above idea does not appear to work do you see any issue >> with instead reverting your changes just for the cairo device driver >> using the attached patch? >> >> That patch is, of course, just a temporary measure until you can look >> in more detail at this whole problem post-release, but it does seem to >> give good results for all of the test_c_xcairo, test_extcairo, and >> test_extXdrawable targets consistent with what we had before for 5.11.0. >> > That would work and we wouldn't be any worse off then we were before. > >> 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 >> __________________________ >> <cairo.patch.gz> > > ------------------------------------------------------------------------------ > _______________________________________________ > Plplot-devel mailing list > Plplot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/plplot-devel ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
