segfault when trying to use wlr_foreign_toplevel_manager_v1 protocol

[RedBearAK]

@flacjacket @m-col

I have been attempting to utilize the foreign toplevel management/manager protocol for some time now, and made a detailed comment about the issues I've been running into with both pywayland and pywlroots over on the pywayland repo (including a sample of the script I've been using to test things):

flacjacket/pywayland#24 (comment)

This issue is specifically about the segmentation fault I get when I try to use pywlroots to use that protocol. Without knowing what I'm doing, I got a simplified report out of valgrind.

`valgrind` output (click to expand):

==7391== Memcheck, a memory error detector
==7391== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==7391== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info
==7391== Command: python3 ./query_topl_mgmt_protocol.py
==7391== Parent PID: 2698
==7391== 
--7391-- WARNING: Serious error when reading debug info
--7391-- When reading debug info from /usr/lib64/libpython3.12.so.1.0:
--7391-- get_Form_contents: DW_FORM_GNU_strp_alt used, but no alternate .debug_str
--7391-- WARNING: Serious error when reading debug info
--7391-- When reading debug info from /usr/bin/python3.12:
--7391-- get_Form_contents: DW_FORM_GNU_strp_alt used, but no alternate .debug_str
--7391-- WARNING: Serious error when reading debug info
--7391-- When reading debug info from /usr/lib64/python3.12/lib-dynload/_elementtree.cpython-312-x86_64-linux-gnu.so:
--7391-- get_Form_contents: DW_FORM_GNU_strp_alt used, but no alternate .debug_str
--7391-- WARNING: Serious error when reading debug info
--7391-- When reading debug info from /usr/lib64/python3.12/lib-dynload/pyexpat.cpython-312-x86_64-linux-gnu.so:
--7391-- get_Form_contents: DW_FORM_GNU_strp_alt used, but no alternate .debug_str
==7391== Invalid read of size 8
==7391==    at 0x1391DF65: wl_list_insert (wayland-util.c:47)
==7391==    by 0x13918F8E: wl_global_create (wayland-server.c:1304)
==7391==    by 0x1386A314: wlr_foreign_toplevel_manager_v1_create (wlr_foreign_toplevel_management_v1.c:692)
==7391==    by 0x1379BC3E: _cffi_f_wlr_foreign_toplevel_manager_v1_create (wlroots._ffi.c:5903)
==7391==    by 0x4A7B6CA: cfunction_vectorcall_O (methodobject.c:509)
==7391==    by 0x4A73CEB: PyObject_Vectorcall (pycore_call.h:92)
==7391==    by 0x497BA2C: _PyEval_EvalFrameDefault.cold (bytecodes.c:2714)
==7391==    by 0x4A997CC: method_vectorcall (call.c:419)
==7391==    by 0x497C166: _PyEval_EvalFrameDefault.cold (call.c:387)
==7391==    by 0x1443052E: general_invoke_callback (_cffi_backend.c:6201)
==7391==    by 0x144307B9: cffi_call_python (call_python.c:276)
==7391==    by 0x13DE577A: dispatcher_func (pywayland._ffi.c:1008)
==7391==  Address 0x100000008 is not stack'd, malloc'd or (recently) free'd
==7391== 
==7391== 
==7391== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==7391==  Access not within mapped region at address 0x100000008
==7391==    at 0x1391DF65: wl_list_insert (wayland-util.c:47)
==7391==    by 0x13918F8E: wl_global_create (wayland-server.c:1304)
==7391==    by 0x1386A314: wlr_foreign_toplevel_manager_v1_create (wlr_foreign_toplevel_management_v1.c:692)
==7391==    by 0x1379BC3E: _cffi_f_wlr_foreign_toplevel_manager_v1_create (wlroots._ffi.c:5903)
==7391==    by 0x4A7B6CA: cfunction_vectorcall_O (methodobject.c:509)
==7391==    by 0x4A73CEB: PyObject_Vectorcall (pycore_call.h:92)
==7391==    by 0x497BA2C: _PyEval_EvalFrameDefault.cold (bytecodes.c:2714)
==7391==    by 0x4A997CC: method_vectorcall (call.c:419)
==7391==    by 0x497C166: _PyEval_EvalFrameDefault.cold (call.c:387)
==7391==    by 0x1443052E: general_invoke_callback (_cffi_backend.c:6201)
==7391==    by 0x144307B9: cffi_call_python (call_python.c:276)
==7391==    by 0x13DE577A: dispatcher_func (pywayland._ffi.c:1008)
==7391==  If you believe this happened as a result of a stack
==7391==  overflow in your program's main thread (unlikely but
==7391==  possible), you can try to increase the size of the
==7391==  main thread stack using the --main-stacksize= flag.
==7391==  The main thread stack size used in this run was 8388608.
==7391== 
==7391== HEAP SUMMARY:
==7391==     in use at exit: 9,288,992 bytes in 68,655 blocks
==7391==   total heap usage: 238,491 allocs, 169,836 frees, 37,030,841 bytes allocated
==7391== 
==7391== LEAK SUMMARY:
==7391==    definitely lost: 64 bytes in 1 blocks
==7391==    indirectly lost: 0 bytes in 0 blocks
==7391==      possibly lost: 8,017,983 bytes in 59,075 blocks
==7391==    still reachable: 1,268,929 bytes in 9,558 blocks
==7391==         suppressed: 0 bytes in 0 blocks
==7391== Rerun with --leak-check=full to see details of leaked memory
==7391== 
==7391== For lists of detected and suppressed errors, rerun with: -s
==7391== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)

I hope someone has some idea what's going wrong here, and whether it's something I'm doing wrong or something that needs to be fixed in the handler code for this protocol that was added in #63.

This happened in both sway and Hyprland on Fedora 40, in a QEMU/KVM virtual machine.

[Consolatis]

pywlroots is a wrapper for wlroots, a library for compositors. You'd need some client library instead if I understand your use-case correctly (interacting with windows on a running wlroots based compositor). An alternative would be to use something like wlrctl or lswt.

[RedBearAK]

pywlroots is a wrapper for wlroots, a library for compositors. You'd need some client library instead if I understand your use-case correctly (interacting with windows on a running wlroots based compositor). An alternative would be to use something like wlrctl or lswt.

@Consolatis

I had been wondering about that actually. Thanks for clearing that up. And I've also been thinking of looking for some alternative external tools to try to use, thought I wonder what kind of trouble I'm going to run into getting those external tools working on all the different distro types I'm currently supporting in the project where I had tried to use pywlroots. We'll see.

Thanks for the links.

[RedBearAK]

I got some tips and was shown a PR on the pywayland repo that fixed my major issue with using pywayland for this protocol, and I was able to get it working. The working version of the script is in a new comment on that issue linked in the first comment here.

The wlrctl utility doesn't seem to be relevant to my use case, but lswt might turn out to be useful for troubleshooting, seeing the info that should come out.

Since this issue came from me misunderstanding the purpose of pywlroots, I'll close it out.