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!
No comments:
Post a Comment