search for: x11devicedriv

...8/04/19 11:39 AM, peter dalgaard wrote: > I had a look at the current code, and AFAICT it has essentially the same structure as it did back then. I think it may have finally dawned upon me what the issue really is: > > The logic is that in Rf_addX11Device, we have > > if (!X11DeviceDriver(dev, display, width, height, > ps, gamma, colormodel, maxcubesize, > bgcolor, canvascolor, sfonts, res, > xpos, ypos, title, useCairo, antialias, family)) { > free(dev); >...

...#ifndef HAVE_PNG error("No png support in this version of R"); #endif if (!(fp = R_fopen(R_ExpandFileName(dsp+5), "w"))) error("could not open PNG file `%s'", dsp+6); ... So what does the comment imply? If error jumps out to the toplevel without giving X11DeviceDriver a chance to free dd and xd, then this should be: if (!strncmp(dsp, "png::", 5)) { FILE *fp; #ifndef HAVE_PNG free (xd); free (dd); error("No png support in this version of R"); #endif if (!(fp = R_fopen(R_ExpandFileName(dsp+5), "w"))) {...

...> >This was the story, R-core November 29, 2001. Part of thread "X11 still segfaults". > >------------>> >..... >Gah. I've been too tired today. Why did that take me so long? > >The culprit seems to be > >R_ProcessEvents((void*) NULL) > >in newX11DeviceDriver > >This gets called *before* this stuff at the end of Rf_addX11Device > > dd = GEcreateDevDesc(dev); > addDevice((DevDesc*) dd); > initDisplayList((DevDesc*) dd); > >and it is that "dd" that gets called by Rf_playDisplayList. Removing >the offending line stops...

...39 AM, peter dalgaard wrote: >>> I had a look at the current code, and AFAICT it has essentially the same structure as it did back then. I think it may have finally dawned upon me what the issue really is: >>> The logic is that in Rf_addX11Device, we have >>> if (!X11DeviceDriver(dev, display, width, height, >>> ps, gamma, colormodel, maxcubesize, >>> bgcolor, canvascolor, sfonts, res, >>> xpos, ypos, title, useCairo, antialias, family)) { >>>...

I had a look at the current code, and AFAICT it has essentially the same structure as it did back then. I think it may have finally dawned upon me what the issue really is: The logic is that in Rf_addX11Device, we have if (!X11DeviceDriver(dev, display, width, height, ps, gamma, colormodel, maxcubesize, bgcolor, canvascolor, sfonts, res, xpos, ypos, title, useCairo, antialias, family)) { free(dev); errorcall(call, _("...

...28/04/19 11:39 AM, peter dalgaard wrote: >> I had a look at the current code, and AFAICT it has essentially the same structure as it did back then. I think it may have finally dawned upon me what the issue really is: >> The logic is that in Rf_addX11Device, we have >> if (!X11DeviceDriver(dev, display, width, height, >> ps, gamma, colormodel, maxcubesize, >> bgcolor, canvascolor, sfonts, res, >> xpos, ypos, title, useCairo, antialias, family)) { >> free(dev);...

...ned in my bug report, I checked using gdb that ConfigureNotify is indeed being received by the call to R_ProcessX11Events() when it is uncommented. I haven't experienced any segfaults. It's good that Peter left evidence that "R_ProcessX11Events" was being called 18 years ago from X11DeviceDriver(). If he had deleted the line, rather than commenting it, then discovering the reason for the window rendering bug would have been much harder for me. However, the downside is that now it is not just a matter of inserting the line where it belongs; I also feel a bit like I have to explain why it...

...ebe0] [ 5] /usr/lib64/libX11.so.6(_XOpenLC+0x104) [0x3c87665674] [ 6] /usr/lib64/libX11.so.6(_XlcCurrentLC+0x8) [0x3c87665768] [ 7] /usr/lib64/libX11.so.6(XSupportsLocale+0x9) [0x3c87665b59] [ 8] /usr/lib64/R/modules//R_X11.so(X11_Open+0x51) [0x2aaab8a32581] [ 9] /usr/lib64/R/modules//R_X11.so(X11DeviceDriver+0x19a) [0x2aaab8a336aa] [10] /usr/lib64/R/modules//R_X11.so [0x2aaab8a33c30] [11] /usr/lib64/R/lib/libR.so [0x3659cff75e] [12] /usr/lib64/R/lib/libR.so(Rf_eval+0x427) [0x3659ccc2d7] [13] /usr/lib64/R/lib/libR.so [0x3659ccd6a2] [14] /usr/lib64/R/lib/libR.so(Rf_eval+0x427) [0x3659ccc2d7] [15]...

...; ConfigureNotify is indeed being received by the call to >> R_ProcessX11Events() when it is uncommented. I haven't experienced any >> segfaults. >> >> It's good that Peter left evidence that "R_ProcessX11Events" was being >> called 18 years ago from X11DeviceDriver(). If he had deleted the >> line, rather than commenting it, then discovering the reason for the >> window rendering bug would have been much harder for me. >> >> However, the downside is that now it is not just a matter of inserting >> the line where it belongs; I...

...ed using gdb that > ConfigureNotify is indeed being received by the call to > R_ProcessX11Events() when it is uncommented. I haven't experienced any > segfaults. > > It's good that Peter left evidence that "R_ProcessX11Events" was being > called 18 years ago from X11DeviceDriver(). If he had deleted the > line, rather than commenting it, then discovering the reason for the > window rendering bug would have been much harder for me. > > However, the downside is that now it is not just a matter of inserting > the line where it belongs; I also feel a bit like...

OK, so I did the archaeology anyway.... This was the story, R-core November 29, 2001. Part of thread "X11 still segfaults". ------------>> ..... Gah. I've been too tired today. Why did that take me so long? The culprit seems to be R_ProcessEvents((void*) NULL) in newX11DeviceDriver This gets called *before* this stuff at the end of Rf_addX11Device dd = GEcreateDevDesc(dev); addDevice((DevDesc*) dd); initDisplayList((DevDesc*) dd); and it is that "dd" that gets called by Rf_playDisplayList. Removing the offending line stops the segfaulting, seemingly with no...

Problem compiling R. version: 0.64.2 machine: SGI O2 OS: IRIX6.5 CC cc FC f77 MAKE GNU make 3.75 Here is part of the the output for make. make[2]: Leaving directory `/usr/people/faculty/math/mgass/stage/R/R-0.64.2/src/include' make[2]: Entering directory `/usr/people/faculty/math/mgass/stage/R/R-0.64.2/src/appl' cc -g -OPT:IEEE_NaN_inf=ON -I../include