Open yijianli-autra opened 1 year ago
Thanks for the report.
Can confirm this fails on the latest 20221107 distributions. The x86_64-unknown-linux-gnu distribution fails for me on the >>> label = tkinter.Label(frame, text="Hello, World")
line:
>>> label = tkinter.Label(frame, text="Hello, World")
[xcb] Unknown sequence number while appending request
[xcb] Most likely this is a multi-threaded client and XInitThreads has not been called
[xcb] Aborting, sorry about that.
python3: ../../src/xcb_io.c:157: append_pending_request: Assertion `!xcb_xlib_unknown_seq_number' failed.
Fatal Python error: Aborted
Current thread 0x00007f7f676b5c40 (most recent call first):
File "/home/gps/src/python-build-standalone/dist/python/lib/python3.9/tkinter/__init__.py", line 2572 in __init__
File "/home/gps/src/python-build-standalone/dist/python/lib/python3.9/tkinter/__init__.py", line 3148 in __init__
File "<stdin>", line 1 in <module>
Aborted (core dumped)
This program works with other Python builds on my system. So something is amiss.
The xcb
warnings point to a potential interaction with that library. I reckon we're missing a configure flag somewhere in the X11 libraries which results in something using a non-standard config. tk and/or CPython is probably making assumptions about some X library config that aren't true.
There's possibly an upstream bug or two to report in here somewhere. But I don't know what until root cause is understood.
Here's an excerpt from libxcb's configure:
Package: libxcb 1.13.1
Configuration
XDM support.........: no
sendmsg fd passing..: yes
Build unit tests....: no
with html results.: no
XCB buffer size.....: 16384
X11 extensions
Composite...........: yes
Package: libxcb 1.13.1
Configuration
XDM support.........: no
sendmsg fd passing..: yes
Build unit tests....: no
with html results.: no
XCB buffer size.....: 16384
X11 extensions
Composite...........: yes
Damage..............: yes
Dpms................: yes
Dri2................: yes
Damage..............: yes
Dpms................: yes
Dri2................: yes
Dri3................: yes
GenericEvent........: no
Glx.................: yes
Randr...............: yes
Record..............: yes
Render..............: yes
Dri3................: yes
GenericEvent........: no
Glx.................: yes
Randr...............: yes
Record..............: yes
Render..............: yes
Resource............: yes
Screensaver.........: yes
Resource............: yes
Screensaver.........: yes
selinux.............: no
Shape...............: yes
Shm.................: yes
Sync................: yes
Xevie...............: no
Xfixes..............: yes
Xfree86-dri.........: yes
selinux.............: no
Shape...............: yes
Shm.................: yes
Sync................: yes
Xevie...............: no
Xfixes..............: yes
Xfree86-dri.........: yes
xinerama............: yes
xinput..............: yes
xkb.................: yes
xprint..............: no
xtest...............: yes
xinerama............: yes
xinput..............: yes
xkb.................: yes
xprint..............: no
xtest...............: yes
xv..................: yes
xvmc................: yes
Used CFLAGS:
CPPFLAGS............: -fvisibility=hidden -fPIC
CFLAGS..............: -fvisibility=hidden -fPIC
Installation:
Prefix..............: /tools/deps
xv..................: yes
xvmc................: yes
Used CFLAGS:
CPPFLAGS............: -fvisibility=hidden -fPIC
CFLAGS..............: -fvisibility=hidden -fPIC
Installation:
Prefix..............: /tools/deps
I have no clue how to interpret any of it though.
(I wish all configure scripts gave you concise reports of important metadata like this!)
And from libx11
:
11 will be built with the following settings:
Loadable i18n module support: no
Loadable xcursor library support: yes
Threading support: yes
Use Threads safe API: yes
Threads stubs in libX11: no
XCMS: yes
Internationalization support: yes
XF86BigFont support: yes
XKB support: yes
XLOCALEDIR environment variable support: yes
Compose table cache enabled: yes
Functional specs building enabled: yes
X11 will be built with the following settings:
Loadable i18n module support: no
Loadable xcursor library support: yes
Threading support: yes
Use Threads safe API: yes
Threads stubs in libX11: no
XCMS: yes
Internationalization support: yes
XF86BigFont support: yes
XKB support: yes
XLOCALEDIR environment variable support: yes
Compose table cache enabled: yes
Functional specs building enabled: yes
Threads stubs in libX11
seems potentially relevant.
OK. We compile tk with -DTCL_THREADS=1
. And we see some code in tk calling XInitThreads()
(it is the only caller of XInitThreads()
I found outside libX11 source, so I think this is the only relevant caller).
However, that code in tk (unix/tkUnixEvent.c
) is protected behind an #if 0 && defined(XKEYCODETOKEYSYM_IS_DEPRECATED) && defined(TCL_THREADS)
. That will never be true. So we never call XInitThreads()
.
I think the problem here is we build tcl/tk with support for threads? Is this somehow different from how the entire world builds tcl/tk?
Note that I enabled threads in commit 169bdadd6ed2de0d2940ba600c73af2709608aa9. But sadly didn't leave any context. (Very uncharacteristic of me!) Commits around it were part of enabling tcl/tk to build on macOS. I wonder if I enabled threads for a reason or just saw they weren't enabled and figured enabling threads was a good idea?
Hmmm. /usr/lib/x86_64-linux-gnu/tclConfig.sh
and /usr/lib/x86_64-linux-gnu/tkConfig.sh
on my machine (Ubuntu 22.04) says we built with TCL_THREADS=1
. I wonder why my machine's tk is working but this one isn't...
To add on to the debugging - I cannot reproduce when using xvfb in Docker or otherwise
Could it perhaps be related to the change mentioned here? https://github.com/indygreg/python-build-standalone/issues/95#issuecomment-1127021925
After a git bisect testing against OP code, I found that this commit is the first bad commit. I have no idea about how to fix this though !
I am using the bazel/rules_python to compile our python code. according to the configuration, we are using the cpython-3.9.13+20220802-x86_64-unknown-linux-gnu-install_only.tar.gz as our python interpreter. But as we are using the Tkinter, there is a segment fault during the runtime. the code
the stack trace
according to other tickets, seems the python interpreter is already linked to the Tkinter.
Update
I was trying to use the debug version to know what happened in the core dump. but it is very strange that I am able to run this with python3.9d. it is very weird.