Bug 175966
| Summary: | gvim shows corrupt buttons | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Pete Zaitcev <zaitcev> | ||||
| Component: | xorg-x11-server | Assignee: | Adam Jackson <ajax> | ||||
| Status: | CLOSED EOL | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 23 | CC: | alexandre.magaz, mcepl, mgahagan, rjones, twaugh, xgl-maint | ||||
| Target Milestone: | --- | Keywords: | Reopened, Triaged | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2016-12-20 11:54:43 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Pete Zaitcev
2005-12-16 19:26:51 UTC
Created attachment 122344 [details]
screenshot
works just fine here with vim-X11-6.4.007-2 and vim-X11-7.0.000-1, please try those and reopen when the bug is still reproducable. Note: This looks more like an gtk2 rendering bug to me I'm sure it's not specifically gvim's fault. I saw Azureus doing it, of all things. But it's not ubiqutous. Never happens to Ethereal, for example. I just hoped you'd have some ideas where to look. sounds like a bug in the xorg driver.. what xorg driver are you using? Actually. I'm fairly sure there's something more subtle at work. The MIT-SHM extension still shows up in the extension list when using X forwarding. MIT-SHM does attempt to notice when the client is non-local, but the ssh client _does_ appear to be local, it's using a Unix socket after all. So you fall through to the next failure check, which is that if you're on different machines, the server's shmat() to the segment provided by the client should fail. Except, it only fails statistically; if there are shm segments on both machines with the same shmid, the server's shmat() will succeed. If this happens to be the shm segment for the gnome icon cache... Pete, next time this happens, run 'ipcs' on both machines and see if this is the case. On display host: ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 32768 zaitcev 600 393216 2 dest 0x00000000 65537 zaitcev 600 393216 2 dest 0x00000000 98306 zaitcev 600 393216 2 dest 0x00000000 131075 zaitcev 600 393216 2 dest 0x00000000 163844 zaitcev 600 393216 2 dest 0x00000000 196613 zaitcev 600 393216 2 dest 0x00000000 229382 zaitcev 600 393216 2 dest 0x00000000 262151 zaitcev 600 393216 2 dest 0x00000000 294920 zaitcev 600 393216 2 dest 0x00000000 327689 zaitcev 600 393216 2 dest 0x00000000 425994 zaitcev 600 393216 2 dest 0x00000000 4325387 zaitcev 600 393216 2 dest 0x00000000 1540108 zaitcev 600 393216 2 dest 0xae5256c1 1802254 zaitcev 660 64528 0 On application host after the failure: ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 32768 zaitcev 600 393216 1 dest If application starts normally, there's no shared segment. Well that explains that. I think the correct solution here is for openssh to mangle the connection block to remove the MIT-SHM extension, although we should probably also best-effort this in xtrans and always consider processes named 'ssh' to be non-local. Reassigning to xserver. I built a (terrible) hack for this in the newest X server in rawhide (xorg-x11-server-1.4.99.1-0.13.fc9). Give it a try. Looks like it works, after a restart of sshd. It just reccured now. The ipcs shows: key shmid owner perms bytes nattch status 0x00000000 65537 zaitcev 600 393216 1 dest Segment 65537 exists at the display host. Installed xorg packages: xorg-x11-apps-7.3-1.fc8 xorg-x11-docs-1.3-1.fc7 xorg-x11-drivers-7.2-10.fc9 xorg-x11-drv-acecad-1.1.0-5.fc8 xorg-x11-drv-aiptek-1.0.1-5.fc8 xorg-x11-drv-apm-1.1.1-2.1 xorg-x11-drv-apm-1.1.1-7.fc8 xorg-x11-drv-ark-0.6.0-6.fc8 xorg-x11-drv-ast-0.81.0-6.fc8 xorg-x11-drv-ati-6.7.196-1.fc8 xorg-x11-drv-avivo-0.0.1-6.fc8 xorg-x11-drv-calcomp-1.1.0-4.fc8 xorg-x11-drv-chips-1.1.1-5.fc8 xorg-x11-drv-cirrus-1.1.0-5.fc8 xorg-x11-drv-citron-2.2.0-2.fc7 xorg-x11-drv-digitaledge-1.1.0-4.fc8 xorg-x11-drv-dmc-1.1.0-3.fc7 xorg-x11-drv-dummy-0.2.0-6.fc9 xorg-x11-drv-dynapro-1.1.0-3.fc7 xorg-x11-drv-elographics-1.1.0-4.fc8 xorg-x11-drv-evdev-1.2.0-1.fc9 xorg-x11-drv-fbdev-0.3.1-4.20071113.fc9 xorg-x11-drv-fpit-1.1.0-4.fc8 xorg-x11-drv-glint-1.1.1-7.fc8 xorg-x11-drv-hyperpen-1.1.0-5.fc8 xorg-x11-drv-i128-1.2.1-1.fc8 xorg-x11-drv-i740-1.1.0-5.fc8 xorg-x11-drv-i810-2.2.0-1.fc9 xorg-x11-drv-jamstudio-1.1.0-4.fc8 xorg-x11-drv-keyboard-1.2.2-3.fc9 xorg-x11-drv-magellan-1.1.0-4.fc8 xorg-x11-drv-magictouch-1.0.0.5-5.fc8 xorg-x11-drv-mga-1.4.6.1-6.fc8 xorg-x11-drv-microtouch-1.1.0-2.fc7 xorg-x11-drv-mouse-1.2.3-3.fc9 xorg-x11-drv-mutouch-1.1.0-5.fc8 xorg-x11-drv-nouveau-2.1.6-2.fc9 xorg-x11-drv-nv-2.1.6-2.fc9 xorg-x11-drv-openchrome-0.2.900-7.fc9 xorg-x11-drv-palmax-1.1.0-4.fc8 xorg-x11-drv-penmount-1.1.0-3.fc7 xorg-x11-drv-rendition-4.1.3-5.fc8 xorg-x11-drv-s3-0.5.0-5.fc8 xorg-x11-drv-s3virge-1.9.1-5.fc8 xorg-x11-drv-savage-2.1.3-1.fc8 xorg-x11-drv-siliconmotion-1.5.1-3.fc8 xorg-x11-drv-sis-0.9.3-4.fc8 xorg-x11-drv-sisusb-0.8.1-9.fc8 xorg-x11-drv-spaceorb-1.1.0-4.fc8 xorg-x11-drv-summa-1.1.0-4.fc8 xorg-x11-drv-tdfx-1.3.0-6.fc8 xorg-x11-drv-tek4957-1.1.0-4.fc8 xorg-x11-drv-trident-1.2.3-6.fc8 xorg-x11-drv-tseng-1.1.0-7.fc8 xorg-x11-drv-ur98-1.1.0-4.fc8 xorg-x11-drv-v4l-0.1.1-8.fc8 xorg-x11-drv-vesa-1.3.0-11.20071113.fc9 xorg-x11-drv-vga-4.1.0-5.fc8 xorg-x11-drv-via-0.2.2-4.fc8 xorg-x11-drv-vmmouse-12.4.3-1.fc8 xorg-x11-drv-vmware-10.15.2-1.fc8 xorg-x11-drv-void-1.1.1-7.fc9 xorg-x11-drv-voodoo-1.1.1-1.fc8 xorg-x11-filesystem-7.1-2.fc6 xorg-x11-fonts-100dpi-7.2-4.fc9 xorg-x11-fonts-75dpi-7.2-4.fc9 xorg-x11-fonts-ISO8859-1-100dpi-7.2-4.fc9 xorg-x11-fonts-ISO8859-1-75dpi-7.2-4.fc9 xorg-x11-fonts-misc-7.2-4.fc9 xorg-x11-fonts-truetype-7.2-4.fc9 xorg-x11-fonts-Type1-7.2-4.fc9 xorg-x11-font-utils-7.2-2.fc8 xorg-x11-proto-devel-7.3-7.fc9 xorg-x11-server-common-1.4.99.1-0.13.fc9 xorg-x11-server-devel-1.4.99.1-0.13.fc9 xorg-x11-server-utils-7.3-2.fc9 xorg-x11-server-Xorg-1.4.99.1-0.13.fc9 xorg-x11-twm-1.0.3-1.fc8 xorg-x11-util-macros-1.1.5-1.fc7 xorg-x11-utils-7.3-1.fc8 xorg-x11-xauth-1.0.2-3.fc8 xorg-x11-xfs-1.0.5-1.fc8 xorg-x11-xinit-1.0.7-2.fc8 xorg-x11-xkb-utils-7.2-3.fc8 xorg-x11-xtrans-devel-1.0.3-5.fc8 Grr. Well, the patch in the X server is definitely doing its job at rejecting XShmAttach() calls from ssh clients. Perhaps we need to be more aggressive and should mangle the connection block on the server side? I'm loathe to try to hack that into ssh, its knowledge of X protocol is politely described as primitive. I did not realize that the patch was applied to the server size, which probably wasn't updated at the time. Please give me a day or two to retest (I started using screen(1) and vi to avoid this, so I don't have the test data right away). Bureaucratic nitpicking -- let's keep this open, until you retest it. Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. It works now. You won't believe it, but it reoccured just now. On display server, ipcs: ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 0 root 644 72 0 0x00000000 32769 root 644 16384 0 0x00000000 65538 root 644 280 0 0x00000000 98307 root 644 72 0 0x00000000 131076 root 644 16384 0 0x00000000 163845 root 644 280 0 0x00000000 294918 zaitcev 600 393216 2 dest 0x00000000 327687 zaitcev 600 393216 2 dest 0x00000000 360456 zaitcev 600 393216 2 dest 0x00000000 393225 zaitcev 600 393216 2 dest 0x00000000 425994 zaitcev 600 393216 2 dest 0x00000000 458763 zaitcev 600 393216 2 dest 0x00000000 491532 zaitcev 600 393216 2 dest 0x00000000 524301 zaitcev 600 393216 2 dest 0x00000000 557070 zaitcev 600 393216 2 dest 0x0056a4d5 30507023 zaitcev 600 488 1 0x00000000 688144 zaitcev 600 393216 2 dest 0x0056a4d6 30539793 zaitcev 600 65536 1 0x00000000 26476562 zaitcev 600 393216 2 dest 0x00000000 26509331 zaitcev 600 393216 2 dest 0x00000000 33226772 zaitcev 600 393216 2 dest 0x00000000 2752533 zaitcev 600 12288 2 dest 0x00000000 2785302 zaitcev 600 393216 2 dest 0x00000000 2818071 zaitcev 600 12288 2 dest 0x00000000 3309592 zaitcev 600 393216 2 dest 0x00000000 33259545 zaitcev 600 393216 2 dest 0x00000000 33292314 zaitcev 600 12288 2 dest 0x00000000 33652763 zaitcev 600 393216 2 dest 0x00000000 33685532 zaitcev 600 393216 2 dest 0x00000000 33718301 zaitcev 600 12288 2 dest 0x00000000 33914911 zaitcev 600 393216 2 dest 0x00000000 33947680 zaitcev 600 393216 2 dest 0x00000000 33980449 zaitcev 600 12288 2 dest 0x00000000 34570274 zaitcev 600 393216 2 dest 0x00000000 34603043 zaitcev 600 393216 2 dest 0x00000000 34635812 zaitcev 600 12288 2 dest 0x00000000 34996261 zaitcev 600 393216 2 dest 0x00000000 35029030 zaitcev 600 393216 2 dest 0x00000000 35061799 zaitcev 600 12288 2 dest On application system, ipcs: ------ Shared Memory Segments -------- key shmid owner perms bytes nattch status 0x00000000 0 root 644 72 0 0x00000000 32769 root 644 16384 0 0x00000000 65538 root 644 280 0 0x00000000 98307 root 644 72 0 0x00000000 131076 root 644 16384 0 0x00000000 163845 root 644 280 0 0x00000000 294918 zaitcev 600 393216 1 dest 0x00000000 327687 zaitcev 600 393216 1 dest I don't quite know what this means, so I looked at PIDs just in case (who knows when it occurs again!). ------ Shared Memory Creator/Last-op -------- shmid owner cpid lpid 0 root 1465 1465 32769 root 1465 1465 65538 root 1465 1465 98307 root 1488 1488 131076 root 1488 1488 163845 root 1488 1488 294918 zaitcev 10005 10005 327687 zaitcev 10009 10009 Processes 1465, 1488 do not exist anymore. I'm sure they have some- thing to do with the system startup. The 10005 and 10009 do not exist either, but 10006 and 10010 are gvim instances. Since gvim backgrounds itself, they must be gvims. Just in case - on server: ------ Shared Memory Creator/Last-op -------- 294918 zaitcev 2325 1964 327687 zaitcev 2386 5706 2335: scim-panel-gtk -- no, srsly 1964: X 2386: gnome-panel 5706: [does not exist] ssh is 5933 xorg-x11-server-utils-7.3-3.fc9.x86_64 xorg-x11-server-Xorg-1.4.99.901-16.20080401.fc9.x86_64 xorg-x11-server-common-1.4.99.901-16.20080401.fc9.x86_64 Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping I see this on occation with firefox, thunderbird and a few other random apps when run remotely for probably over 2 years. I've thought it might be a gtk or other related toolkit issue, but have never been able to isolate the problem and reproduce reliably, but I probably see it about 10% of the time with various combinations of RHEL 5, Fedora 8,9. Come to think of it, I have never seen a kde app do this that I can remember which sort of lead me to believe this might be a tool kit issue. This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Since this bugzilla report was filed, there have been several major updates in various components of the Xorg system, which may have resolved this issue. Users who have experienced this problem are encouraged to upgrade their system to the latest version of their packages. For packages from updates-testing repository you can use command yum upgrade --enablerepo='*-updates-testing' Alternatively, you can also try to test whether this bug is reproducible with the upcoming Fedora 12 distribution by downloading LiveMedia of F12 Beta available at http://alt.fedoraproject.org/pub/alt/nightly-composes/ . By using that you get all the latest packages without need to install anything on your computer. For more information on using LiveMedia take a look at https://fedoraproject.org/wiki/FedoraLiveCD . Please, if you experience this problem on the up-to-date system, let us now in the comment for this bug, or whether the upgraded system works for you. If you won't be able to reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you. [This is a bulk message for all open Fedora Rawhide Xorg-related bugs. I'm adding myself to the CC list for each bug, so I'll see any comments you make after this and do my best to make sure every issue gets proper attention.] It has been a really long time since I have seen this issue, but I will keep an eye out for it for the next week or so and try and reproduce it if it happens on one of my F12 systems. Very easy to reproduce xorg-x11-server-common-1.7.0-1.fc12.x86_64 libX11-1.3-1.fc12.x86_64 This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping libX11-1.3.1-3.fc13.x86_64 xorg-x11-server-common-1.8.2-4.fc13.x86_64 I take it, since Ajax's attempt to fix in 2007, nothing else was found to be possible. Maybe we should just wontfix this? This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '13'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 13's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 13 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This message is a notice that Fedora 15 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 15. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At this time, all open bugs with a Fedora 'version' of '15' have been closed as WONTFIX. (Please note: Our normal process is to give advanced warning of this occurring, but we forgot to do that. A thousand apologies.) Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, feel free to reopen this bug and simply change the 'version' to a later Fedora version. Bug Reporter: Thank you for reporting this issue and we are sorry that we were unable to fix it before Fedora 15 reached end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" (top right of this page) and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Apparently this could be fixed after this commit was added to the X server: http://cgit.freedesktop.org/xorg/xserver/commit/?id=e2c7d70e5ddb8b17676a13ceebfbb87d14d63243 It requires two additional fixes to openssh and libX11: <quote source="ajax"> So at this point we just need client support, which I think is: a) hack openssh to do the new handshake b) add XLIB_FORCE_REMOTE=1 support to libX11 </quote> Should bugs be filed for those items then? They don't seem to be fixed yet. This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle. Changing version to '23'. (As we did not run this process for some time, it could affect also pre-Fedora 23 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23 This message is a reminder that Fedora 23 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 23. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '23'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 23 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 23 changed to end-of-life (EOL) status on 2016-12-20. Fedora 23 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |