El 1/9/23 a las 9:00, Rafael Sadowski escribió:
On Sat Jul 22, 2023 at 07:51:15AM +0200, Matthieu Herrb wrote:
On Thu, Jul 20, 2023 at 08:32:30PM +0200, Rafael Sadowski wrote:
On Thu Jul 20, 2023 at 04:31:55PM +0100, Stuart Henderson wrote:
On 2023/07/20 17:27, Rafael Sadowski wrote:
Let's start with a quote from an old try:
"Our Xorg server doesn't run under the same uid as the client, the client
needs to create the shared memory area with mode 0666.
We are doing the same in misc/screen-shm. Of course, the consequence
here would be to do it for all Qt applications."
-- https://marc.info/?l=openbsd-ports&m=167110468109188&w=2
There was a veto from sthen@, which was perfectly okay and right. For
error analysis and to exclude that this function is not used, I need the
shm mode from time to time. I would like to solve it with an environment
variable (QT_OPENBSD_SHM_MODE).
From that mail,
"What are the consequences of leaving this as-is? (i.e. what's broken
now that changing this would fix?)"
Nothing is broken and nothing is would fix for now. It just helps me to
debug Qt application or large ecosystem like KDE plasma. When I increase
the debug level I see that shm could not be init and therefore I can not
exclude that exactly this is a problem.
Long story short: It helps me not to always have to build Qt myself.
Are there still places in the Qt library that don't use
xcb_shm_attach_fd() to attach shared memory segments to the X server ?
No, it looks like they are using this pattern:
It starts here:
286 if (!QXcbBackingStore::createSystemVShmSegment(m_xcbConnection)) {
287 qCDebug(lcQpaXcb, "failed to create System V shared memory segment
(remote "
288 "X11 connection?), disabling SHM");
289 m_hasShm = m_hasShmFd = false;
290 }
409 bool QXcbBackingStoreImage::createSystemVShmSegment(xcb_connection_t
*c, size_t segmen
410
xcb_shm_segment_info_t *shmInfo)
411 {
412 const int id = shmget(IPC_PRIVATE, segmentSize, IPC_CREAT | 0600);
413 if (id == -1) {
414 qCWarning(lcQpaXcb, "shmget() failed (%d: %s) for size %zu",
errno, strerror(e
415 return false;
416 }
417
418 void *addr = shmat(id, nullptr, 0);
419 if (addr == (void *)-1) {
420 qCWarning(lcQpaXcb, "shmat() failed (%d: %s) for id %d", errno,
strerror(errno
421 return false;
422 }
423
424 if (shmctl(id, IPC_RMID, nullptr) == -1)
425 qCWarning(lcQpaXcb, "Error while marking the shared memory
segment to be destr
426
427 const auto seg = xcb_generate_id(c);
428 auto cookie = xcb_shm_attach_checked(c, seg, id, false);
429 auto *error = xcb_request_check(c, cookie);
430 if (error) {
431 qCWarning(lcQpaXcb(), "xcb_shm_attach() failed");
Or in sort:
412 const int id = shmget(IPC_PRIVATE, segmentSize, IPC_CREAT | 0600);
425 const auto seg = xcb_generate_id(c);
426 auto cookie = xcb_shm_attach_checked(c, seg, id, false);
427 auto *error = xcb_request_check(c, cookie);
431 qCWarning(lcQpaXcb(), "xcb_shm_attach() failed");
https://github.com/qt/qtbase/blob/5.15/src/plugins/platforms/xcb/qxcbbackingstore.cpp#L424
There is no different path for Linux/FreeBSD here.
This was introduced more than 10 years ago, so that if the X server is
not running as root it can still access shared memory segments created
by the clients, possibly running as a different uid as the server, and
preserving the privacy of the shm contents.
In that case 600 is perfectly fine and applications don't need to
fallback on non-shm based transports.
If Qt is using xcb_shm_attach() or XShmAttach() is that only on
OpenBSD because it thinks OpenBSD doesn't have xcb_shm_attach_fd(),i
ot is it the same on Linux ? (since Linux is not running X as root
anymore either whith systemd, they would face the same issues as you).
$ dolphin # OpenBSD with ports qtbase
qt.scaling: Apply QT_SCALE_FACTOR 1
qt.qpa.xcb: Has MIT-SHM : true
qt.qpa.xcb: Has MIT-SHM FD : true
qt.qpa.xcb: xcb_shm_attach() failed
qt.qpa.xcb: failed to create System V shared memory segment (remote X11
connection?), disabling SHM
qt.qpa.xcb: Using XInput version 2.2
$ dolphin # Linux Debian sid
qt.qpa.xcb: Has MIT-SHM : true
qt.qpa.xcb: Has MIT-SHM FD : true
qt.qpa.xcb: Using XInput version 2.2
PS: I remember we once noticed that mesa was also not using
xcb_shm_attach_fd() on OpenBSD. I should have a look to confirm this,
but I'm not available for the next 2 weeks to do that, sorry.
--
Matthieu Herrb
Hi! From my ignorance I have the following question:
Is it likely that this SHM problem in QT5, has some strange interaction
with PyQT5, programs that need access to SHM under certain conditions
and the death of a Xenocara session?
You see, I have opened this bug:
https://marc.info/?l=openbsd-bugs&m=169362096621051&w=2
It appears only under very specific conditions. Example: you run a
software with PyQT5 using QTMultimedia (either to play music or video),
and Xenocara dies instantly. I suspect this bug is related to the
handling of SHM and XCB in QT5, and the interaction these two elements
have with Xenocara/DRM in OpenBSD.
@Raphael, I understand that you have QT5 patched with this more
permissive mode for SHM (0666), correct? Would it be too much trouble to
try to install and run picard (2.8.5p0 in packages/ports) and test if
with this mode the Xenocara crash problem appears or not?
This way we verify if the picard crash is due to the very restrictive
mode in QT5 SHM, and at the same time, we have a reason for a patch to
make it less restrictive, like the one you mentioned.
Thanks!
