Tk Source Code

Following script

label .a -text [string repeat 0 0x1000]
grid configure .a -row 1 -column 1

causes a crash wish following error messages:

X Error of failed request:  BadAlloc (insufficient resources for operation)
  Major opcode of failed request:  53 (X_CreatePixmap)
  Serial number of failed request:  102
  Current serial number in output stream:  104

Any multiplier between 0x1000 and 0x1fff cause a crash. With multipliers >= 0x2000 only the number of zeros over 0x2000 is displayed. Multiplier between 0x3000 and 0x3fff crashes again.

The width of "0" in the used font is 8 pixels. Seems there is an integer overflow.

Jan merged the improved test into core-9-0-branch by commit [3fca5ed4] and into main by commit [909a5f45]. Now I performed the missing merge into core-8-6-new by commit [2d437e24]. Closing the ticket (again), with resolution "Fixed".

The revised test does not lock up my system.

In [0309359d58] Don disabled unixbutton-3.1 because it locked up his system. I ran the test multiple times in Xvfb and on a real display in Xwayland, and did not notice any issues. My guess is that the cause is the button, which was huge in both directions and needed a 32767x32767 pixmap: 4 GB in Xvfb, 8 GB of GPU buffers in Xwayland here. With less memory, or with a GPU with less video memory, this can stall the whole system. Proposed fix in branch [5c892c0523]: each widget is huge in one direction only, which tests the same limits with pixmaps of a few MB, and the test is enabled again. Don, could you please test it on your system?

The test gridded the three widgets, so the toplevel became about 120112x80023, beyond the 16-bit limit of X window sizes. When . is already mapped by previous tests, as in a full test run, the X server truncates its size and grid shrinks the widgets. Fixed in [2cf953f38c]: the widgets are now placed, so the toplevel is not resized. Without the fix the test still crashes with an X error.

Unfortunately, the new test case unixbutton-3.1 in unixButton.test failed in the CI run of last night. Before committing the merge, I had tested it successfully via

    make test TESTFLAGS="-verbose bps -file ../tests/unixButton.test"

but it failed in the CI and also in the complete manual test started via

    make test

I have spent a lot of time to find out why the two methods behave differently, but without success.

By replacing the winfo width and winfo height invocations with winfo reqwidth and winfo reqheight, the resulting test passes with both methods, but I am not sure whether this would be the right workaround.

Serhiy, many thanks for the ticket and the fix! Merged into main, core-9-0-branch, and core-8-6-branch by commits [bc5e8ae5], [f3849ef4], and [dee12bec].

Proposed fix in branch x11-pixmap-size-limit: Tk_GetPixmap() clips the size to 32767, the largest size the X server accepts (32768 to 65535 fail with BadAlloc, larger sizes with BadValue). Drawing beyond it is lost, but there is no crash. New test unixbutton-3.1.

There are several (old) tickets in this repository showing various issues boiling down to dimensions exceeding what a short int can handle (+/-32767). Not all of them are pathological though.

A non exhaustive list is [3307625fff], [2421792fff] and [770578fff]. In the latter ticket, a comment by dkf on 2004-02-16 says it all about the philosophy in those cases.

This crash still happens on 8.6.10, and will likely continue to do so. The crash occurs when Tk_GetPixmap() (a wrapper for XCreatePixmap()) is called from TkpDisplayButton() (tkUnixButton.c), using the width of the label: 0x1000 * 8 = 0x8000 = 32768 (plus any borders or padding), which exceeds 32767—the maximum value for signed 16 bit integers, and the inherent limit for dimensions in X11. (Once the width exceeds 65535, as for 0x2000 * 8 = 65536, the width is interpreted as having wrapped around 0.)

I don't know whether Tk should clip dimensions to avoid crashes, or argue that these cases are too unusual to merit workarounds. Non-X11 windowing systems appear to lack limitations like this one, and X11 is simply no longer the windowing system of the future.

Doesn't crash on Windows (Vista).