Bug in program depends on number of tiled windows

John Jumper

10 Mar 2012 10 Mar '12

11:24 p.m.

I am trying to isolate and/or work around a bug in the R statistics software (r-project.org), and the bug seems to depend on how many windows are managed by a tiling layout, regardless of how many windows are in a float layout. I am using R 2.14.2 and Xmonad 0.9.2. Steps to reproduce: $ R

...

dev.new() ; plot(1, main='plot 1') dev.new() ; plot(1, main='plot 2') dev.new() ; plot(1, main='plot 3') # plot 2 is now blank # floating any of the plot windows and then resizing the tiled layout causes # all plot windows to draw correctly dev.new() ; plot(4, main='plot 4') # now plot 3 is blank

Opening terminals does not cause problems, so I do not think the problem can be related to the size of the tiled window, only to the number of tiled plot windows. Any time there are more than two tiled plot windows, at most two will draw. The number of floating plot windows does not matter, which puzzles me. I cannot find any difference using xprop between a floating and tiled window. I would like to file an appropriate bug report with R or create a workaround in my Xmonad configuration that still allows me to tile the windows. Is there an important property that distinguishes tiled and floating windows from the perspective of X, rather than Xmonad? Thank you.

Show replies by date

Wirt Wolff

11 Mar 11 Mar

5:54 p.m.

Excerpts from John Jumper's message of Sat Mar 10 21:24:31 -0700 2012:

...

I am trying to isolate and/or work around a bug in the R statistics software (r-project.org), and the bug seems to depend on how many windows are managed by a tiling layout, regardless of how many windows are in a float layout. I am using R 2.14.2 and Xmonad 0.9.2.

Steps to reproduce: $ R

...
dev.new() ; plot(1, main='plot 1') dev.new() ; plot(1, main='plot 2') dev.new() ; plot(1, main='plot 3') # plot 2 is now blank # floating any of the plot windows and then resizing the tiled layout causes # all plot windows to draw correctly dev.new() ; plot(4, main='plot 4') # now plot 3 is blank

I'm looking into this bit by bit, but I suspect I've not enough X11 and C knowlege, nor time, to do more than list symptoms. The R codebase is pretty well documented, but it's large and complex. I can definitely reproduce something like this, although what draws and doesn't draw seems to be a bit different here. I'm still cataloging results under different conditions, so I've not made much sense of it yet. FWIW I'm running R in a small urxvt floating scratchpad, not a tiled terminal. Also FWIW R doesn't set resize hints (which would be very plot dependent anyway.) It sets only location and size. With two, three, or four, all but the newest are blank until resized, so far as I can tell with just a few tests. Mod-n to refresh and focus changes do nothing, but any xmonad operation that resizes triggers redrawing. Another weird symptom is that with 3 plots, the third plotted and the first two blank... changing to an empty workspace and then back to the plot workspace draws two of the plots but not consistently. Sometimes 1 and 3 get drawn, and other times 2 and 3. :/ Toggling plots to and from full-screen also give unpredictable behavior. However, if I leave the misbehaving workspace on one monitor, and then plot some more on the other monitor (move the scratchpad to that monitor) they all consistently plot fine. It's very confusing so far. I tried your reproduction steps with a very minimal build of R, to eliminate the cairo and tk code from consideration, and before that with my normal build. Both acted strangely with tiling layouts. So far here it seems as if already drawn plots get cleared when the new one resizes all of them, and they don't get redrawn until they are resized again, but that's not the whole story even if it's correct. As a workaround till the real problem gets identified, my normal R workflow /might/ work for you. I have always floated my R plots, since I want to preview them at correct size to print to pdf or png. Using the hook className =? "" --> doFloat accomplishes that. That in itself is enough to draw plots correctly, but forces you to specify sizes and possibly locations in the code, unless you manually move them around and change focus. I use Actions.Navigation2D for the navigation, as it easily moves between the float and tiled layer and navigates or swaps directionally. I use the mouse to move the windows, and if needed resize, via A.FlexibleManipulate. For z-order, I use swapUp swapDown on the mouse-wheel. Also, there are snap and float key modules in xmonad-contrib, for manipulating floats from the keyboard that might be useful if you work with a lot of plots at once.

...

....

Is there an important property that distinguishes tiled and floating windows from the perspective of X, rather than Xmonad?

Perhaps some of the X11 experts on the list can help with that question. -- Regards, wmw

Brandon Allbery

9:01 p.m.

On Sun, Mar 11, 2012 at 17:54, Wirt Wolff wrote:

...

With two, three, or four, all but the newest are blank until resized, so far as I can tell with just a few tests.

Mod-n to refresh and focus changes do nothing, but any xmonad operation that resizes triggers redrawing.

Another weird symptom is that with 3 plots, the third plotted and the first two blank... changing to an empty workspace and then back to the plot workspace draws two of the plots but not consistently. Sometimes 1 and 3 get drawn, and other times 2 and 3. :/

...

Toggling plots to and from full-screen also give unpredictable behavior.

Somehow I'm thinking R is waiting until some negotiation is complete, that xmonad thinks is already complete. I'm curious as to whether it relies on libX11/xcb/whatever toolkit it's using handling ConfigureRequest or tries to do so itself; that's the most obvious difference between the various cases *and* where xmonad is likely to differ from other window managers. I'd be curious as to whether any problems have been reported with R in other nonreparenting or tiling window managers. (Note, the two are not the same thing.) -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

John Jumper

12 Mar 12 Mar

12:21 a.m.

On Sun, Mar 11, 2012 at 8:01 PM, Brandon Allbery wrote:

...

On Sun, Mar 11, 2012 at 17:54, Wirt Wolff wrote:

...
With two, three, or four, all but the newest are blank until resized, so far as I can tell with just a few tests.

Mod-n to refresh and focus changes do nothing, but any xmonad operation that resizes triggers redrawing.

Another weird symptom is that with 3 plots, the third plotted and the first two blank... changing to an empty workspace and then back to the plot workspace draws two of the plots but not consistently. Sometimes 1 and 3 get drawn, and other times 2 and 3. :/

Toggling plots to and from full-screen also give unpredictable behavior.

Somehow I'm thinking R is waiting until some negotiation is complete, that xmonad thinks is already complete. I'm curious as to whether it relies on libX11/xcb/whatever toolkit it's using handling ConfigureRequest or tries to do so itself; that's the most obvious difference between the various cases *and* where xmonad is likely to differ from other window managers.

I'd be curious as to whether any problems have been reported with R in other nonreparenting or tiling window managers. (Note, the two are not the same thing.)

-- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

I looked at the documentation for x11() in R, and the default is to use type="X11". If I install the Cairo library 1.5_1 for R and launch two CairoX11 plots, I get a segfault whenever I resize. I will probably file this as a bug report with the R developers. The segfault should be much easier to track down that drawing bugs. gdb output (using R -d gdb):

...

library('Cairo'); CairoX11() ; CairoX11()

Program received signal SIGSEGV, Segmentation fault. 0x009f6704 in Rcairo_backend_resize (be=0xceb0, width=570, height=296) at cairotalk.c:1025 1025 if (!be || !be->dd) return; I do not know if this has been reproduced with other tiling window managers. John

Wirt Wolff

14 Mar 14 Mar

6:51 a.m.

Excerpts from John Jumper's message of Sun Mar 11 22:21:16 -0600 2012:

...

On Sun, Mar 11, 2012 at 8:01 PM, Brandon Allbery wrote:

I looked at the documentation for x11() in R, and the default is to use type="X11". If I install the Cairo library 1.5_1 for R and launch two CairoX11 plots, I get a segfault whenever I resize. I will probably file this as a bug report with the R developers. The segfault should be much easier to track down that drawing bugs.

gdb output (using R -d gdb):

...
library('Cairo'); CairoX11() ; CairoX11()

Program received signal SIGSEGV, Segmentation fault. 0x009f6704 in Rcairo_backend_resize (be=0xceb0, width=570, height=296) at cairotalk.c:1025 1025 if (!be || !be->dd) return;

I do not know if this has been reproduced with other tiling window managers.

I also get segfaults using the Cairo CRAN library. Since R gave the message 'memory not mapped' I suspected pax kernel protection might be causing this. However, CairoX11() still segfaults when creating the second graphics device, even after disabling all pax protections on library/Cairo/libs/Cairo.so. It looks to me, though, that the built-in X11.options(type='cairo') provides everything the Cairo library does, so the Cairo package may be obsolete at this point. The same drawing problems occur using R built without cairographics or tk support (always uses Xlib devices), and using R built with cairo support, i.e. X11.options(type='cairo'). I have verified that the same broken drawing occurs in i3 and in dwm, even including the unpredictable results when toggling to and from fullscreen or empty workspaces. So this isn't xmonad specific. Best regards, wmw

Brandon Allbery

10:59 p.m.

On Wed, Mar 14, 2012 at 06:51, Wirt Wolff wrote:

...

I have verified that the same broken drawing occurs in i3 and in dwm, even including the unpredictable results when toggling to and from fullscreen or empty workspaces. So this isn't xmonad specific.

So R is broken with nonreparenting window managers in general. You should probably file a bug against R; there is not a lot that xmonad can do about it. :/ (The similar situation with some Java programs used to be worked around by finding that the JRE knew about some nonreparenting window managers, then making xmonad pretend to be one of the known ones.) -- brandon s allbery allbery.b@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

Wirt Wolff

7:15 a.m.

Excerpts from Wirt Wolff's message of Sun Mar 11 15:54:18 -0600 2012:

...

However, if I leave the misbehaving workspace on one monitor, and then plot some more on the other monitor (move the scratchpad to that monitor) they all consistently plot fine.

This is incorrect. Multiple monitors doesn't make any difference. Since I couldn't reproduce this in i3 or dwm I went back and checked in xmonad. The only reason that it might have worked, I thought, was having a status bar on one of the monitors. But I can't get this to happen at all any more. So I must have done something differently or just plain been mistaken the first time. Regards, wmw

4816

Age (days ago)

4820

Last active (days ago)

List overview

Download

6 comments

3 participants

participants (3)

Brandon Allbery
John Jumper
Wirt Wolff