[Bug 1956062] Re: vim mis-manages modifyOtherKeys on xterms
What version of vim is planned for 22.04? Will these fixes be included? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956062 Title: vim mis-manages modifyOtherKeys on xterms To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1956062/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956062] Re: vim mis-manages modifyOtherKeys on xterms
Examining the raw I/O between this new vim and my xterm, I see that the 'r' command is now turning off modifyOtherKeys (and then back on after the replacement character is typed). So, it would appear that there is a fix to this upstream, and Ubuntu vim is just lacking that fix. As far as use of ^V in a ":s/" search command, it appears that vim is simply properly interpreting "^[[27;5;109~" now, rather than inserting the whole sequence literally. So, it appears that the version of vim currently in 20.04 is lacking some fixes. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956062 Title: vim mis-manages modifyOtherKeys on xterms To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1956062/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956062] Re: vim mis-manages modifyOtherKeys on xterms
I cloned the vim github repo and did a default build (version 8.2.4014), that version of vim does not exhibit any of this odd behavior. Seems likely that either something has fixed this upstream or else Ubuntu 20.04 vim build enables some feature that causes this. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956062 Title: vim mis-manages modifyOtherKeys on xterms To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1956062/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1956062] [NEW] vim mis-manages modifyOtherKeys on xterms
Public bug reported: This began as question #76. I've observed odd behavior in vim since my upgrade from 18.04 to 20.04. One in particular is when I use the "r" command to replace a single character, shifted letters fail to work correctly and vim sputters and changes the case of letters in the line, instead of replace a single character. Another place is in search strings where I want to use the carriage-return character and type Ctrl-V Ctrl-M, the Ctrl-M appears as an ESC sequence instead of "^M" and the search fails to do what I intended. Analyzing the problem in question #76 revealed this: When vim initializes (the xterm), it sends "^[[>4;2m" which sets the modifyOtherKeys=2 parameter. This appears to send *any* keys that use modifiers (Shift, Ctrl, Alt) as ESC sequences, as we've seen. This explains why the un-shifted keys "r" and "s" appear normally. But, it appears that there are certain cases where vim is not properly interpreting the sequences that it requested. In the case of the "s" command, vim sends an "^[[>4;m" (modifyOtherKeys=0) before I can type the "A", so the "A" comes in as a normal ASCII character. It appears that vim should also be doing the same thing for "r" but does not. There are probably other contexts where vim is failing to properly manage the modifyOtherKeys setting, such as when I try ^V^M in search commands. In the case of the "r" command, vim sends no ESC sequences after the "r" so the "A" comes in as the ESC sequence "^[[27;2;65~" and confuses vim. In the case of search commands, vim is also failing to reset the modifyOtherKeys setting, so the ^V and ^M are sent as ESC sequences - although it appears that vim recognizes the ^V "^[[27;5;118~" and then (correctly) ignores the ESC in the ^M sequence "^[[27;5;109~". FYI, I understand that vim can now recognize "\r" in search strings, but that still leaves the problem of all the other control characters I must often manipulate in search commands. It is looking now as though there is actually a bug in vim, where it does not properly manage the modifyOtherKeys setting even though it explicitly requests that setting. ProblemType: Bug DistroRelease: Ubuntu 20.04 Package: vim 2:8.1.2269-1ubuntu5.4 ProcVersionSignature: Ubuntu 5.4.0-91.102-generic 5.4.151 Uname: Linux 5.4.0-91-generic x86_64 ApportVersion: 2.20.11-0ubuntu27.21 Architecture: amd64 CasperMD5CheckResult: skip CurrentDesktop: ubuntu:GNOME Date: Thu Dec 30 15:49:03 2021 InstallationDate: Installed on 2017-02-22 (1772 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) ProcEnviron: TERM=xterm PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: vim UpgradeStatus: Upgraded to focal on 2020-10-04 (451 days ago) ** Affects: vim (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug focal -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1956062 Title: vim mis-manages modifyOtherKeys on xterms To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/1956062/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1909838] Re: gcc -O3 produces invalid code
Turns out, this is due to the programmer's assumption that fcb->name[8] and fcb->ext[3] can be accessed contiguously by fcb->name[0..10]. So, the code is actually "lazy", if not bad. Obviously, this has worked in C for a long time but no longer can be depended on. ** Changed in: gcc-9 (Ubuntu) Status: New => Invalid -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1909838 Title: gcc -O3 produces invalid code To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1909838/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1909838] Re: gcc -O3 produces invalid code
I've discovered that "-Og" does produce working, somewhat-optimized, code. Still, I need to understand why this code was appearing to the optimizer as a no-op. I need to make sure that no other code is being incorrectly optimized. As it stands, this looks to me to be erroneous optimization by GCC. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1909838 Title: gcc -O3 produces invalid code To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1909838/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1909838] Re: gcc -O3 produces invalid code
Here's the latest code example, eliminating the need for the cpmutl.h header file ** Attachment added: "stand-alone match_fcb.c example" https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1909838/+attachment/5448725/+files/match_fcb.c -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1909838 Title: gcc -O3 produces invalid code To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1909838/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1909838] Re: gcc -O3 produces invalid code
I see that gcc-7 also has the same issue. I'm starting to wonder if this code is flawed, but I don't see the problem. I would have thought "-O3" is pretty safe and sane. I could imagine -O5 doing something like this. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1909838 Title: gcc -O3 produces invalid code To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1909838/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1909838] Re: gcc -O3 produces invalid code
On a hunch, I added "volatile" to the declarations of the function parameters: int match_fcb(volatile struct cpmfcb *mask, volatile struct cpmfcb *fcb) This caused code to be generated, and it looks viable. It's still unclear to me why this code was being optimized away. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1909838 Title: gcc -O3 produces invalid code To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1909838/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1909838] Re: gcc -O3 produces invalid code
** Package changed: ubuntu => gcc-9 (Ubuntu) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1909838 Title: gcc -O3 produces invalid code To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gcc-9/+bug/1909838/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1909838] Re: gcc -O3 produces invalid code
** Attachment added: "Additional (header) file needed to compile." https://bugs.launchpad.net/ubuntu/+bug/1909838/+attachment/5448651/+files/cpmutl.h -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1909838 Title: gcc -O3 produces invalid code To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1909838/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1909838] [NEW] gcc -O3 produces invalid code
Public bug reported: If I compile the attached file with -O3, gcc produces an empty function (simply returns 0). If I compile without -O3, gcc produces viable code that functions as expected. Linux outhouse 5.4.0-58-generic #64-Ubuntu SMP Wed Dec 9 08:16:25 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux gcc 4:9.3.0-1ubuntu2 ** Affects: ubuntu Importance: Undecided Status: New ** Attachment added: "Sample program that demonstrates problem" https://bugs.launchpad.net/bugs/1909838/+attachment/5448643/+files/match_fcb.c -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1909838 Title: gcc -O3 produces invalid code To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1909838/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1831908] [NEW] JLabel does not render image in HTML tags
Public bug reported: The example program creates a JLabel with text set to "". On previous versions of the openjdk-8-jre, this would work and the PNG was displayed in the JLabel. On the current version, 8u212-b03-0ubuntu1.18.04.1, all that is rendered is a tiny label with no apparent image inside. I have run the same class file on a RHEL 7 system with JRE 1.8.0_201, and on the original 18.04 JRE 1.8.0_162 and it works as expected. I believe this also worked correctly on 8u191-b12-2ubuntu0.18.04.1. ProblemType: Bug DistroRelease: Ubuntu 18.04 Package: openjdk-8-jre 8u212-b03-0ubuntu1.18.04.1 ProcVersionSignature: Ubuntu 4.15.0-50.54-generic 4.15.18 Uname: Linux 4.15.0-50-generic x86_64 ApportVersion: 2.20.9-0ubuntu7.6 Architecture: amd64 CurrentDesktop: ubuntu:GNOME Date: Thu Jun 6 09:21:54 2019 InstallationDate: Installed on 2017-02-22 (834 days ago) InstallationMedia: Ubuntu 16.04.2 LTS "Xenial Xerus" - Release amd64 (20170215.2) ProcEnviron: PATH=(custom, no user) XDG_RUNTIME_DIR= LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: openjdk-8 UpgradeStatus: Upgraded to bionic on 2018-09-09 (269 days ago) ** Affects: openjdk-8 (Ubuntu) Importance: Undecided Status: New ** Tags: amd64 apport-bug bionic ** Attachment added: "Test setup demonstrating bug, includes results screenshots, pass and fail." https://bugs.launchpad.net/bugs/1831908/+attachment/5269158/+files/bug20190605.tgz -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1831908 Title: JLabel does not render image in HTML tags To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1831908/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1831908] Re: JLabel does not render image in HTML tags
The results screenshot test-java1.8.0_212.png shows how it fails to render the image. test-java1.8.0_162.png shows success on the original 18.04 version of the JRE. Note, in all cases if I specify an image file that does not exist, all version properly render a JLabel of appropriate size. So, it would seems that the bug exists after the image file is successfully loaded. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1831908 Title: JLabel does not render image in HTML tags To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openjdk-8/+bug/1831908/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1566400] Re: Ubuntu 16.04 testing with PMC 12GB Series 8 adapter with MaxView RAID Migration deletes the RAID array.
The corresponding bug for this issue has been closed as unreproducible. Unclear why that was not communicated here. This launchpad can also be closed. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1566400 Title: Ubuntu 16.04 testing with PMC 12GB Series 8 adapter with MaxView RAID Migration deletes the RAID array. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1566400/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1670634] Re: blk-mq: possible deadlock on CPU hot(un)plug
Carsten, I am currently thinking there are two possibilities here. Maybe three. 1) The fix I submitted is not in the kernel(s) you are running. 2) The s390 compiler does not produce the necessary code to implicitly convert long int to bool. 3) You are hitting a different bug that just happens to look the same. For #2, a simple compiler test could be done to check what code is produced when assigning a long int value to a bool (GCC _Bool). If you want to pursue that let me know. I am not familiar with s390 object code, so we might need someone to interpret the objdump. As far as I can tell, the s390 Linux kernel does use GCC _Bool for the data type "bool", so it would then be a matter of what code the s390 GCC produces in this case. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1670634 Title: blk-mq: possible deadlock on CPU hot(un)plug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1670634/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1670634] Re: blk-mq: possible deadlock on CPU hot(un)plug
I'm confused about the release mechanics, I guess. Looking at the git repository, I see tag "Ubuntu-4.4.0-65.86" (for example) and that tag commit does contain the fix. Is it then possible for a kernel labeled "4.4.0-65-generic #86" to NOT contain that patch? Am I making a gross assumption that these tags reflect what was released? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1670634 Title: blk-mq: possible deadlock on CPU hot(un)plug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1670634/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1670634] Re: blk-mq: possible deadlock on CPU hot(un)plug
This looks a lot like the problem in LP #1662673, but that fix is supposed to be in kernel 4.4.0-65-generic. Might be worth confirming though. Or perhaps confirming that the fix actually works on the Z architecture (depends on how the architecture/compiler handles 'bool'). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1670634 Title: blk-mq: possible deadlock on CPU hot(un)plug To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1670634/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
