[plasmashell] [Bug 341143] Bring back per-virtual-desktop wallpapers
https://bugs.kde.org/show_bug.cgi?id=341143 Jody changed: What|Removed |Added CC||o...@jsankey.com --- Comment #328 from Jody --- Just re-remembered this issue installing Kubuntu 20.04 as I have every LTS release since KDE 5 :-(. My use case is to separate the things I work on into a small number of long term buckets that I can keep separate on my screen and in my head. This doesn't sound too unusual. Both virtual desktops and activities sound like they should be able to do this but both have pain points. Activities: + Customizing wallpaper and application launcher by activity is great - Order-by-last-use makes this unusable for me with more than two activities: I can't predict which activity I'm going to move to with a "next" keypress and the keybindings to jump to a specific activity are broken for me in Kubuntu 20.04. The inability to customize transition effects means the transition doesn't help ground the user in a sequence (horizontal slide with side-by-side monitors is particularly unhelpful), and I can't even get activities in the switcher to appear in a sane order (e.g. alphabetical). This introduces a lot of cognitive overhead around a transition that breaks flow. - Moving a window between activities is a bit clumsy due to the per-activity toggling. - All of the UI for managing activities feels a little "unfinished" to me. Virtual Desktops: + The desktop cube animation provides a great visual metaphor that keeps the relationship between the spaces clear. + Cycling between desktops is predictable and the key bindings work. + Moving windows between desktops is easy. - The inability to customize wallpaper by desktop means there are few visual cues as to the current location in the sequence. For the last 4 years I've been using activities and limited myself to 2 activities to avoid the switching issues. This time I'm going with 3 virtual desktops and trying to live with the fact they all look the same. Trying either "remember desktop per activity" or vallpaper led to broken animations during transition that were more distracting for me than the benefit they provided. I've been using KDE for 11 years now and I really do appreciate all the work the devs put in, but in this area it feels we're lacking the big picture of what user needs should be solved and how to provide functionality that works well together to meet these needs. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 --- Comment #33 from jody --- I encountered the same kind of error vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFE 0x8 0x6F 0x46 0x1 0xC5 0xF8 0x11 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==15878== valgrind: Unrecognised instruction at address 0x4a0ed10. in a C++ application using std::map and std::string. Should i give more details? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 --- Comment #31 from jody --- Are there any recommendations on compiler switches for gcc? Do some newer ersions of it use AVX512 by default? -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 --- Comment #26 from jody --- Here's a link to the dropbox https://tinyurl.com/tmtxhzr -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 --- Comment #24 from jody --- Ok - here it is On Thu, Jan 2, 2020 at 1:32 PM Tom Hughes wrote: > https://bugs.kde.org/show_bug.cgi?id=393351 > > --- Comment #22 from Tom Hughes --- > I was afraid that might happen as it's a local function that isn't > exported... > > Are you able to just gzip the output it and attach it here? > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 --- Comment #21 from jody --- oops - this did not work. Which mail address should i use to share the link with? On Thu, Jan 2, 2020 at 11:59 AM jody wrote: > I did >objdump -d /usr/lib64/libhdf5.so.103.1.0 > > objdump_libhdf5.so.103.1.0.txt > but the string "H5P_dup_prop" is not in the output. > The command 'grep "H5P_d" objdump_libhdf5.so.103.1.0.txt' returns nothing. > The next function in the stack (H5P__do_prop_cb1) does also not occur in > the output of objdump, but all others are. > > I sent a dropbox link for objdump_libhdf5.so.103.1.0.txt to > bug-cont...@kde.org > > > On Thu, Jan 2, 2020 at 12:28 PM Julian Seward > wrote: > >> https://bugs.kde.org/show_bug.cgi?id=393351 >> >> --- Comment #18 from Julian Seward --- >> As Tom says .. >> >> > ==6297== valgrind: Unrecognised instruction at address 0x4a54820. >> > ==6297==at 0x4A54820: H5P_dup_prop+64 (in >> /usr/lib64/libhdf5.so.103.1.0) >> >> > I have no experience at all with objdump. I tried 'objdump -d >> ./h5s_8.3.0' >> >> Nearly, not quite right. The problem is in /usr/lib64/libhdf5.so.103.1.0. >> >> Can you try objdump -d /usr/lib64/libhdf5.so.103.1.0 instead? >> >> Then look for the code near the entry point (to be precise, at offset 64 >> from) >> for H5P_dup_prop. You can find that entry point by searching the objdump >> output for the string >> >> H5P_dup_prop>: >> >> -- >> You are receiving this mail because: >> You are on the CC list for the bug. > > -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 --- Comment #20 from jody --- I did objdump -d /usr/lib64/libhdf5.so.103.1.0 > objdump_libhdf5.so.103.1.0.txt but the string "H5P_dup_prop" is not in the output. The command 'grep "H5P_d" objdump_libhdf5.so.103.1.0.txt' returns nothing. The next function in the stack (H5P__do_prop_cb1) does also not occur in the output of objdump, but all others are. I sent a dropbox link for objdump_libhdf5.so.103.1.0.txt to bug-cont...@kde.org On Thu, Jan 2, 2020 at 12:28 PM Julian Seward wrote: > https://bugs.kde.org/show_bug.cgi?id=393351 > > --- Comment #18 from Julian Seward --- > As Tom says .. > > > ==6297== valgrind: Unrecognised instruction at address 0x4a54820. > > ==6297==at 0x4A54820: H5P_dup_prop+64 (in > /usr/lib64/libhdf5.so.103.1.0) > > > I have no experience at all with objdump. I tried 'objdump -d > ./h5s_8.3.0' > > Nearly, not quite right. The problem is in /usr/lib64/libhdf5.so.103.1.0. > > Can you try objdump -d /usr/lib64/libhdf5.so.103.1.0 instead? > > Then look for the code near the entry point (to be precise, at offset 64 > from) > for H5P_dup_prop. You can find that entry point by searching the objdump > output for the string > > H5P_dup_prop>: > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 --- Comment #15 from jody --- Hi Julian I can still reproduce the failure. When i run valgrind with '--demangle=no --sym-offsets=yes' i get a stack dump as follows: - vex amd64->IR: unhandled instruction bytes: 0x62 0xF1 0xFE 0x8 0x6F 0x45 0x0 0xC5 0xF8 0x11 vex amd64->IR: REX=0 REX.W=0 REX.R=0 REX.X=0 REX.B=0 vex amd64->IR: VEX=0 VEX.L=0 VEX.n=0x0 ESC=NONE vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==6297== valgrind: Unrecognised instruction at address 0x4a54820. ==6297==at 0x4A54820: H5P_dup_prop+64 (in /usr/lib64/libhdf5.so.103.1.0) ==6297==by 0x4A56465: H5P__do_prop_cb1.part.13+85 (in /usr/lib64/libhdf5.so.103.1.0) ==6297==by 0x4A55C01: H5P_create_id+385 (in /usr/lib64/libhdf5.so.103.1.0) ==6297==by 0x4A56155: H5P__init_package+373 (in /usr/lib64/libhdf5.so.103.1.0) ==6297==by 0x4A562C7: H5P_init+39 (in /usr/lib64/libhdf5.so.103.1.0) ==6297==by 0x48CA0ED: H5_init_library+285 (in /usr/lib64/libhdf5.so.103.1.0) ==6297==by 0x48CA90F: H5open+63 (in /usr/lib64/libhdf5.so.103.1.0) ==6297==by 0x1091C8: main+67 (h5simple.cpp:6) - I have no experience at all with objdump. I tried 'objdump -d ./h5s_8.3.0' (h5s_8.3.0 is my test-application compiled with g++ 8.3.0), I see some references to hdf5 calls (e.g. H5open, but no H5P_dup_prop), but i can't really interpret the output. I attached both the output of Valgrind and of objdump to this mail. Let me know how i can be of further help Regards Jody On Sun, Dec 29, 2019 at 10:34 AM Julian Seward wrote: > https://bugs.kde.org/show_bug.cgi?id=393351 > > --- Comment #14 from Julian Seward --- > This bug has been reported 5 times in the past year, as bug numbers 393351, > 40, 414944, 411303 and 414053. I would like to fix it. I tried the > steps-to-reproduce shown in bugs 393351 and 414053, but without success: I > can't reproduce it either with the trunk or with 3.15.0. > > Without being able to reproduce it, I can't fix it. The first unhandled > byte, > 0x62, isn't the start of any known instruction (in 64-bit mode), so I > suspect > there has been some failure earlier on. Maybe Valgrind's instruction > decoder > lost track of where it was on the previous instruction. That's just a > guess, > though. > > What would be really helpful is if someone could reproduce the failure, and > then use objdump -d to show the instructions around the failure point. I > can > give guidance on how to use objdump if that helps. If you want to try > this, I > suggest you first reproduce the failure while giving --demangle=no > --sym-offsets=yes to Valgrind. That will make it much easier to relate the > stack trace that Valgrind produces at the failure point, to the output of > objdump -d. > > -- > You are receiving this mail because: > You are on the CC list for the bug. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 393351] unhandled instruction bytes: 0x62 0xF1 0xFD 0x48 0x6F 0xD 0xE1 0xEC 0x8 0x0
https://bugs.kde.org/show_bug.cgi?id=393351 --- Comment #16 from jody --- Created attachment 124847 --> https://bugs.kde.org/attachment.cgi?id=124847=edit vg_log.txt -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 414053] New: vex amd64->IR: unhandled instruction bytes
https://bugs.kde.org/show_bug.cgi?id=414053 Bug ID: 414053 Summary: vex amd64->IR: unhandled instruction bytes Product: valgrind Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: jody@gmail.com Target Milestone: --- Created attachment 123851 --> https://bugs.kde.org/attachment.cgi?id=123851=edit valgrind log file and sample source code SUMMARY When valgrind is used on an application with hdf5, an "unhandled instruction bytes" error is displayed (cf vg_log.txt) STEPS TO REPRODUCE 1. compile sample program with hdf5: g++ -g h5simple.cpp -lhdf5 -o h5s_9.2.0 2. run it with valgrind valgrind -v --log-file=vg_log.txt ./h5s_9.2.0 OBSERVED RESULT Valgrind halts execution with "unhandled instruction bytes" message. EXPECTED RESULT "Normal" valgrind mem-check operation SOFTWARE/OS VERSIONS Linux aim-frog 4.19.66-gentoo #1 SMP Mon Sep 9 09:32:22 -00 2019 x86_64 Intel(R) Xeon(R) W-2195 CPU @ 2.30GHz GenuineIntel GNU/Linux ADDITIONAL INFORMATION Outside of valgrind the application runs without errors. I could reproduce the error with valgrind versions 3.13.0, 3.14.0, 3.15.0. It is independent of the compiler i used (gcc 6.4.0,7.4.0,8.3.0,9.2.0) The version of hdf5 is 1.10.5 -- You are receiving this mail because: You are watching all bug changes.
