[kwin] [Bug 442643] Overview is empty with non-mirrored multi-screen setup on X11
https://bugs.kde.org/show_bug.cgi?id=442643 --- Comment #4 from Aetf <7437...@gmail.com> --- Can also confirm on my setup: 2 monitors with 2x scale factor. The left monitor is primary. Also, I don't think this is the same issue as Bug 443905. The problem in this issue is that there's nothing shown after activating the effect (windows seem to be animated to somewhere in between the two monitors), while in 443905 the windows are visible but there are flicking. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.23.3 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 5.15.3-arch1-1 (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i7-10750H CPU @ 2.60GHz Memory: 31.2 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 442643] Overview is empty with non-mirrored multi-screen setup on X11
https://bugs.kde.org/show_bug.cgi?id=442643 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 444990] Shortcut conflicts when filename contains number
https://bugs.kde.org/show_bug.cgi?id=444990 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 444990] Shortcut conflicts when filename contains number
https://bugs.kde.org/show_bug.cgi?id=444990 Aetf <7437...@gmail.com> changed: What|Removed |Added Attachment #143223|0 |1 is obsolete|| --- Comment #1 from Aetf <7437...@gmail.com> --- Created attachment 143224 --> https://bugs.kde.org/attachment.cgi?id=143224=edit The tab bar while pressing the alt key -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 444990] New: Shortcut conflicts when filename contains number
https://bugs.kde.org/show_bug.cgi?id=444990 Bug ID: 444990 Summary: Shortcut conflicts when filename contains number Product: okular Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: 7437...@gmail.com Target Milestone: --- Created attachment 143223 --> https://bugs.kde.org/attachment.cgi?id=143223=edit The tab bar while pressing the alt key SUMMARY In Okular by default, you can use Alt+1, Alt+2, etc. to activate annotation tools. However, when you have multiple files open, and there are numbers in the filenames, Alt+1, etc. may be assigned as the tabview keyboard accelerator to switch tabs. In the attached screenshot, it can be seen that the last document "Statement-2021-10.pdf" has "1" underlined, suggesting it is used as the accelerator key. STEPS TO REPRODUCE 1. Open several documents in Okular 2. Make sure one of them gets assigned an accelerator key by pressing alt and see which char is underlined in the tab bar 3. Press Alt+1 OBSERVED RESULT If the current tab is not the one with filename containing "1", Okular will switch to that tab. If already on that tab, an "ambiguous shortcut detected" warning shows up and nothing happens. EXPECTED RESULT Alt+1, Alt+2, etc. always activates the corresponding annotation tool, regardless of filenames of currently opened documents. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.23.2 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 Kernel Version: 5.14.16-arch1-1 (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i7-10750H CPU @ 2.60GHz Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 415683] KSettings > Screen Rotation doesn't rotate touchscreen & generates xinput error
https://bugs.kde.org/show_bug.cgi?id=415683 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 428760] Remap touchscreen to laptop integrated panel on display configuration change
https://bugs.kde.org/show_bug.cgi?id=428760 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 442064] New: the `powermanagement` data engine calling the `UnInhibit` method with incorrect signature
https://bugs.kde.org/show_bug.cgi?id=442064 Bug ID: 442064 Summary: the `powermanagement` data engine calling the `UnInhibit` method with incorrect signature Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: DataEngines Assignee: plasma-b...@kde.org Reporter: 7437...@gmail.com Target Milestone: 1.0 SUMMARY I noticed the Battery and Brightness applet always ends up in a confusing state after using its "Inhibit automatic sleep and screen locking" feature. I tracked it down to the `powermanagement` data engine calling the `UnInhibit` method with incorrect signature: - [when un-inhibit sleep](https://invent.kde.org/plasma/plasma-workspace/-/blob/master/dataengines/powermanagement/powermanagementjob.cpp#L107) - [when un-inhibit screen locking](https://invent.kde.org/plasma/plasma-workspace/-/blob/master/dataengines/powermanagement/powermanagementjob.cpp#L126) The correct signature should take an unsigned int: - [`org.freedesktop.PowerManagement.UnInhibit`](https://invent.kde.org/plasma/powerdevil/-/blob/master/daemon/org.freedesktop.PowerManagement.Inhibit.xml#L10) - [`org.freedesktop.ScreenSaver.UnInhibit`](https://invent.kde.org/plasma/powerdevil/-/blob/master/daemon/org.freedesktop.ScreenSaver.xml#L30) STEPS TO REPRODUCE 1. Make sure nothing is inhibiting ``` qdbus --literal org.kde.Solid.PowerManagement.PolicyAgent \ /org/kde/Solid/PowerManagement/PolicyAgent \ org.kde.Solid.PowerManagement.PolicyAgent.ListInhibitions ``` 2. Check the "Inhibit automatic sleep and screen locking" box in the Battery and Brightness applet 3. Wait 5 seconds for the inhibition to engage and verify the list of inhibitions. There should be 2 items. 4. Uncheck the "Inhibit automatic sleep and screen locking" box in the Battery and Brightness applet OBSERVED RESULT Inhibitions are **not** released. And if you toggle the checkbox multiple times, there will be many duplicated items in the list. If you run ``` dbus-monitor "destination=org.freedesktop.PowerManagement.Inhibit" "sender=org.freedesktop.PowerManagement.Inhibit" ``` during step 4, the error reply will be captured (something similar to the following): ``` error time=1630903644.048537 sender=:1.414 -> destination=:1.57 error_name=org.freedesktop.DBus.Error.UnknownMethod reply_serial=7813 string "No such method 'UnInhibit' in interface 'org.freedesktop.PowerManagement.Inhibit' at object path '/org/freedesktop/PowerManagement/Inhibit' (signature 'i')" ``` EXPECTED RESULT Inhibitions are released. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.85.0 Qt Version: 5.15.2 Kernel Version: 5.13.13-arch1-1 (64-bit) Graphics Platform: X11 Processors: 12 × Intel® Core™ i7-10750H CPU @ 2.60GHz Memory: 31.1 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 404057] Uses an insane amount of memory (RSS/PSS) writing a *ton* of data while re-indexing unchanged files
https://bugs.kde.org/show_bug.cgi?id=404057 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[Skanlite] [Bug 299517] Skanlite should support scan to pdf.
https://bugs.kde.org/show_bug.cgi?id=299517 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 427291] Latte Dock crashes after the external display disconnected
https://bugs.kde.org/show_bug.cgi?id=427291 Aetf <7437...@gmail.com> changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #2 from Aetf <7437...@gmail.com> --- I just tried the debug build of the latest git version, and it no longer crashes. So this is probably fixed already. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 427291] New: Latte Dock crashes after the external display disconnected
https://bugs.kde.org/show_bug.cgi?id=427291 Bug ID: 427291 Summary: Latte Dock crashes after the external display disconnected Product: lattedock Version: 0.9.11 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: 7437...@gmail.com Target Milestone: --- Created attachment 132090 --> https://bugs.kde.org/attachment.cgi?id=132090=edit My layout in use SUMMARY Latte Dock crashes when the external display removed. I use an external display with my laptop's built-in display. The layout I'm using was adapted from the "Topbar and Dock" layout but with some changes: * The top bar appears on both displays. The one on external is set to onPrimary, and the one on built-in is set to on eDP-1 * The dock appears on both displays with similar settings * Plasmoids are changed This setup works well when the external display is connected. However, when it is disconnected, latte-dock crashes. Then, the crash is consistent while the built-int display is the only screen. STEPS TO REPRODUCE 1. Import my layout file 2. latte-dock -r -d --layout XPS OBSERVED RESULT latte-dock crashes. EXPECTED RESULT latte-dock doesn't crash and shows panels correctly. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.19.5 KDE Frameworks Version: 5.74.0 Qt Version: 5.15.1 ADDITIONAL INFORMATION The default layout indeed works fine. So my guess is my settings with the onPrimary/on eDP-1 caused the crash. I then edited the layout to remove the panels set on eDP-1, and latte-dock starts fine. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 427291] Latte Dock crashes after the external display disconnected
https://bugs.kde.org/show_bug.cgi?id=427291 --- Comment #1 from Aetf <7437...@gmail.com> --- Created attachment 132091 --> https://bugs.kde.org/attachment.cgi?id=132091=edit Crash log -- You are receiving this mail because: You are watching all bug changes.
[KScreen] [Bug 323647] Add possibility to run user defined scripts after switching displaysettings
https://bugs.kde.org/show_bug.cgi?id=323647 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 406800] XWayland: bad cursor events after DisplayPort monitor hotplug
https://bugs.kde.org/show_bug.cgi?id=406800 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 424718] Window decoration on maximized window is not large enough to cover all underlaying pixels
https://bugs.kde.org/show_bug.cgi?id=424718 --- Comment #1 from Aetf <7437...@gmail.com> --- Created attachment 130438 --> https://bugs.kde.org/attachment.cgi?id=130438=edit If the window doesn't use window decoration, there is no red pixels visible The same setting as in the report, but with the Vivaldi browser, which doesn't use window decoration. And there is no red pixels visible. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 424718] New: Window decoration on maximized window is not large enough to cover all underlaying pixels
https://bugs.kde.org/show_bug.cgi?id=424718 Bug ID: 424718 Summary: Window decoration on maximized window is not large enough to cover all underlaying pixels Product: kwin Version: 5.19.3 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: 7437...@gmail.com Target Milestone: --- Created attachment 130437 --> https://bugs.kde.org/attachment.cgi?id=130437=edit Maximized window having 1px red line on the left and top edge of the window decoration SUMMARY With scaling factor 150% set, the window decoration on a maximized window is not large enough to cover all underlying pixels, leaving about 1px line on top. STEPS TO REPRODUCE 1. Set the desktop wallpaper to a solid color, like red 2. Maximize any window with server-side decoration (I tried dolphin, vscode, system settings) OBSERVED RESULT There is a 1px red line on the top of the screen. See the attached screenshot. EXPECTED RESULT The window and decoration should fully cover whatever is underneath them. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Archlinux with latest updates (kernel 5.7.10-arch1-1) (available in About System) KDE Plasma Version: 5.19.3 KDE Frameworks Version: 5.72.0 Qt Version: 5.15.0 ADDITIONAL INFORMATION This is on a *Wayland* session. I'm aware of [1], but that happens on X11, and for me the 1px line only appears in the window decoration section. So I think this is a different bug. [1]: https://bugs.kde.org/show_bug.cgi?id=391956 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 417604] Scrolling direction inverted in some Plasma scrollviews
https://bugs.kde.org/show_bug.cgi?id=417604 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 414762] mousearea onClicked dialog popup opens in wrong place unless window is minimized and reopened
https://bugs.kde.org/show_bug.cgi?id=414762 --- Comment #4 from Aetf <7437...@gmail.com> --- My versions: Qt 5.13.2 Plasma 5.17.3 -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 414762] mousearea onClicked dialog popup opens in wrong place unless window is minimized and reopened
https://bugs.kde.org/show_bug.cgi?id=414762 --- Comment #3 from Aetf <7437...@gmail.com> --- Created attachment 124296 --> https://bugs.kde.org/attachment.cgi?id=124296=edit The context menu location is as if the client area starts from (0, 0) I can reproduce on Archlinux with the latest packages. I'm on X. Moving the window does not change the context menu location. But clicking on different locations within the same item, or different items changes the context menu location relatively. In fact, I noticed that if you move the window to the top left corner, with the client area starting from (0, 0), then the context menu location is correct. -- You are receiving this mail because: You are watching all bug changes.
[plasma-nm] [Bug 414762] mousearea onClicked dialog popup opens in wrong place unless window is minimized and reopened
https://bugs.kde.org/show_bug.cgi?id=414762 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 405016] Dock stays visible when moving mouse in and out quickly
https://bugs.kde.org/show_bug.cgi?id=405016 --- Comment #8 from Aetf <7437...@gmail.com> --- (In reply to Michail Vourlakos from comment #7) > Are you using Latte v0.8 or git version? I'm using 0.8.8. But the bug was also there for the previous 0.8.7. But I'm not sure which version exactly did the bug first appeared. -- You are receiving this mail because: You are watching all bug changes.
[lattedock] [Bug 405016] Dock stays visible when moving mouse in and out quickly
https://bugs.kde.org/show_bug.cgi?id=405016 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com --- Comment #6 from Aetf <7437...@gmail.com> --- I have hit the same bug. I have the dock set to "Dodge active". I also have a feeling that the mouse leaving event is somehow not received by latte dock. Here's a video[1] reproducing them with debug window open. 1. at about 0:26, zoom effect not reset after mouse leaving 2. at about 0:42, zoom effect not reset, tooltip not hide, dock not hide 3. at about 1:08, zoom effect not reset [1] https://drive.google.com/open?id=12WYyTzkK9CL_CySGf85ScKkPGaHWq84J -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 372116] Feature Request: Support OSC 52 (copy to clipboard)
https://bugs.kde.org/show_bug.cgi?id=372116 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 389448] Width and height of the window doesn't set correctly on HiDPI screen after upgrade to plasma 5.12
https://bugs.kde.org/show_bug.cgi?id=389448 --- Comment #12 from Aetf <7437...@gmail.com> --- I've found a workaround. Adding/removing virtual desktops seems to force Qt to recalculate the desktop size and makes Yakuake's sizing correct. -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 399731] Symlink layout file not supported
https://bugs.kde.org/show_bug.cgi?id=399731 Aetf <7437...@gmail.com> changed: What|Removed |Added Ever confirmed|0 |1 Resolution|INTENTIONAL |--- Status|RESOLVED|REOPENED --- Comment #2 from Aetf <7437...@gmail.com> --- Please view this as a feature request then. Is there any consideration that symlinks are not supported? -- You are receiving this mail because: You are watching all bug changes.
[latte-dock] [Bug 399731] New: Symlink layout file not supported
https://bugs.kde.org/show_bug.cgi?id=399731 Bug ID: 399731 Summary: Symlink layout file not supported Product: latte-dock Version: unspecified Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: mvourla...@gmail.com Reporter: 7437...@gmail.com Target Milestone: --- SUMMARY The layout config file in $HOME/.config/latte/*.layout.latte can't be a symlink. It will be skipped in layout manager when loading layouts. I use git repo to manage my config files including the latte layout. In previous version (probably 0.7.x), this works. But now I can't use symlinks anymore, which is inconvenient. STEPS TO REPRODUCE 1. Create a new layout or use the default one 2. Move the layout file to somewhere else and use a symlink to point to new location OBSERVED RESULT The layout won't be loaded, and disappears in settings EXPECTED RESULT The layout show up as normal SOFTWARE VERSIONS (available in About System) KDE Plasma Version: 5.14 KDE Frameworks Version: 5.50 Qt Version: 5.11.2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 391897] lldb debugger "setting set takes more arguments"
https://bugs.kde.org/show_bug.cgi?id=391897 Aetf <7437...@gmail.com> changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 391897] lldb debugger "setting set takes more arguments"
https://bugs.kde.org/show_bug.cgi?id=391897 --- Comment #3 from Aetf <7437...@gmail.com> --- Hmm, you are right that the default build does include debug symbols. Not sure why I didn't get it the first time. Did you enable break on start in launch configurations? You can check the Frame Stack tab to see if the program was paused somewhere in main. And program outputs should be printed to Debug tab. Konsole tab is not relevant here. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 391897] lldb debugger "setting set takes more arguments"
https://bugs.kde.org/show_bug.cgi?id=391897 Aetf <7437...@gmail.com> changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED --- Comment #1 from Aetf <7437...@gmail.com> --- This is only a warning and doesn't cause any problem with actual debugging. Anyway, fix posted to https://phabricator.kde.org/D11524 BTW, newly created project uses empty CMAKE_BUILD_TYPE by default, so the built binary doesn't include debug symbols. That's why the debugger seems not working. Try reconfigure cmake in project settings by setting CMAKE_BUILD_TYPE to Debug and rebuild, then the debugger will work correctly. -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 389448] Width and height of the window doesn't set correctly on HiDPI screen after upgrade to plasma 5.12
https://bugs.kde.org/show_bug.cgi?id=389448 --- Comment #3 from Aetf <7437...@gmail.com> --- Some investigation: Given my resolution 3840x2160, It appears that Qt returns screen geometry as 1920x1080, which has been scaled down by QT_SCREEN_SCALE_FACTORS=2. Then in KWindowSystem::workArea, which calls QScreen::geometry internally in X11 plugin[1], the returned value is scaled down the second time[2], and returns 960x540. Therefore yakuake calculates using wrong max height and width of the screen. [1] https://cgit.kde.org/kwindowsystem.git/tree/src/platforms/xcb/kwindowsystem.cpp#n73 [2] https://cgit.kde.org/kwindowsystem.git/tree/src/kwindowsystem.cpp#n599 -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 389448] Width and height of the window doesn't set correctly on HiDPI screen after upgrade to plasma 5.12
https://bugs.kde.org/show_bug.cgi?id=389448 --- Comment #2 from Aetf <7437...@gmail.com> --- Another report of the same bug: https://bugs.kde.org/show_bug.cgi?id=388217 -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 389448] Width and height of the window doesn't set correctly on HiDPI screen after upgrade to plasma 5.12
https://bugs.kde.org/show_bug.cgi?id=389448 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com --- Comment #1 from Aetf <7437...@gmail.com> --- I'm facing the same bug after my upgrade today. I'm using ArchLinux. Versions: yakuake: 3.0.4 plasma: 5.12.0 qt: 5.10.0 I have a 4k monitor running at native resolution 3840x2160. I also set scale display factor to 2, which KDE translates to QT_SCREEN_SCREAN_SCALE_FACTORS. I tried quitting and removing ~/.cache/yakuake and restarting but with no success. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384630] The 'impossible' happened (__ubsan_handle_shift_out_of_bounds) as soon as starting anything under valgrind
https://bugs.kde.org/show_bug.cgi?id=384630 --- Comment #2 from Aetf <7437...@gmail.com> --- I'm using the receipt from spack (https://github.com/LLNL/spack/blob/develop/var/spack/repos/builtin/packages/valgrind/package.py). And yes it was built with --enable-ubsan -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384630] The 'impossible' happened (__ubsan_handle_shift_out_of_bounds) as soon as starting anything under valgrind
https://bugs.kde.org/show_bug.cgi?id=384630 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 384630] New: The 'impossible' happened (__ubsan_handle_shift_out_of_bounds) as soon as starting anything under valgrind
https://bugs.kde.org/show_bug.cgi?id=384630 Bug ID: 384630 Summary: The 'impossible' happened (__ubsan_handle_shift_out_of_bounds) as soon as starting anything under valgrind Product: valgrind Version: 3.13.0 Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: memcheck Assignee: jsew...@acm.org Reporter: 7437...@gmail.com Target Milestone: --- Compiled source, tried both 3.12.0 and 3.13.0. OS: RHEL 7.3 Arch: ppc64le Kernel: 3.10.0 Built with gcc 7.1.0 $ valgrind ls -l ==32450== Memcheck, a memory error detector ==32450== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==32450== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==32450== Command: ls -l ==32450== --32450:0:main:ubs In __ubsan_handle_shift_out_of_bounds valgrind: m_compiler.c:281 (__ubsan_handle_shift_out_of_bounds): the 'impossible' happened. host stacktrace: ==32450==at 0x580AD2C8: show_sched_status_wrk (m_libcassert.c:355) ==32450==by 0x580AD50F: report_and_quit (m_libcassert.c:426) ==32450==by 0x580AD68B: vgPlain_assert_fail (m_libcassert.c:492) ==32450==by 0x58098AE7: __ubsan_handle_shift_out_of_bounds (m_compiler.c:281) ==32450==by 0x58286413: extend_s_16to32 (guest_ppc_toIR.c:559) ==32450==by 0x58286413: dis_int_store.isra.46 (guest_ppc_toIR.c:7430) ==32450==by 0x582A230B: disInstr_PPC_WRK.isra.54 (guest_ppc_toIR.c:28350) ==32450==by 0x582AA4A7: disInstr_PPC (guest_ppc_toIR.c:29533) ==32450==by 0x5826952B: bb_to_IR (guest_generic_bb_to_IR.c:365) ==32450==by 0x58233C83: LibVEX_FrontEnd (main_main.c:558) ==32450==by 0x582346B3: LibVEX_Translate (main_main.c:1173) ==32450==by 0x580E9023: vgPlain_translate (m_translate.c:1794) ==32450==by 0x5815F63B: handle_tt_miss (scheduler.c:1056) ==32450==by 0x5815F63B: vgPlain_scheduler (scheduler.c:1417) ==32450==by 0x5817E04B: thread_wrapper (syswrap-linux.c:103) ==32450==by 0x5817E04B: run_a_thread_NORETURN (syswrap-linux.c:156) sched status: running_tid=1 Thread 1: status = VgTs_Runnable (lwpid 32450) ==32450==at 0x4001880: _start (in /usr/lib64/ld-2.17.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 384368] Support for gdb watchpoint option -location
https://bugs.kde.org/show_bug.cgi?id=384368 Aetf <7437...@gmail.com> changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 384368] New: Support for gdb watchpoint option -location
https://bugs.kde.org/show_bug.cgi?id=384368 Bug ID: 384368 Summary: Support for gdb watchpoint option -location Product: kdevelop Version: unspecified Platform: unspecified OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: CPP Debugger Assignee: kdevelop-bugs-n...@kde.org Reporter: 7437...@gmail.com CC: niko.s...@gmail.com Target Milestone: --- Copying from mailing list thread https://mail.kde.org/pipermail/kdevelop/2017-September/019479.html: > I've set watchpoint with command `watch -l` and it was saved in KDevelop > session. Now it doesn't start debug session because it ends up in endless > loop: > (gdb) 2106-break-watch "-location m_part_spec.start_part" > 2106^error,msg="-break-watch: Unknown option ``location > m_part_spec.start_part''" > (gdb) 2107-break-watch "-location m_part_spec.start_part" > 2107^error,msg="-break-watch: Unknown option ``location > m_part_spec.start_part''" > (gdb) 2108-break-watch "-location m_part_spec.start_part" > 2108^error,msg="-break-watch: Unknown option ``location > m_part_spec.start_part''" > (gdb) 2109-break-watch "-location m_part_spec.start_part" > 2109^error,msg="-break-watch: Unknown option ``location > m_part_spec.start_part''" > (gdb) 2110-break-watch "-location m_part_spec.start_part" > 2110^error,msg="-break-watch: Unknown option ``location > m_part_spec.start_part''" 1. BreakpointModel gets updated when user creating watch points directly using command. The location reported by GDB includes the "-location " part, but since we are quoting the entire string, GDB interprets the entire string as an option, rather than only the "-location" part. 2. Even though we recognize the location and only quote remaining expression, GDB/MI which is the protocol we use to communicate with GDB actually doesn't support "-l/-location" option. see [1] 3. When starts new session, KDevelop tries to automatically reapply all break/watch points saved in BreakpointModel. But the command fails due to above reason. However there shouldn't be an endless loop. Once the command fails, it should set the error message in the Breakpoint toolview and continue. But maybe I'm just missing something. The fix would be 1. In mibreakpointcontroller.cpp:358, detect and quote only the expression part, this is easy. 2. Find a way to emulate the "-location" option. Possible solutions: 2.1 Take the address of the expression when watch point got set and save that in BreakpointModel. But addresses are likely to change between runs 2.2 Simply remove "-location" part and set it as a normal watch point. But likely at the very begining of the program, the expression is out of scope. 2.3 Skip it. IMHO even normal watchpoints should be skipped. As they rely on expressions that are hardly valid at this time. 3. Desired behavior should be display the error in Breakpoint toolview, rather than entering an endless loop. However I didn't find which part of the code is causing the loop after a quick of the codebase. And the desired behavior is already implemented. This will need more investigation. [1] https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Breakpoint-Commands.html#GDB_002fMI-Breakpoint-Commands -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 340283] please add possibility to sort results returned by krunner by type
https://bugs.kde.org/show_bug.cgi?id=340283 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 372635] do not follow mousepointer when accessing krunner via keyboard
https://bugs.kde.org/show_bug.cgi?id=372635 Aetf <7437...@gmail.com> changed: What|Removed |Added Status|CONFIRMED |RESOLVED Latest Commit||https://commits.kde.org/mil ||ou/a41a850a3943dbc1bd43b867 ||def775e41902f987 Resolution|--- |FIXED --- Comment #17 from Aetf <7437...@gmail.com> --- Git commit a41a850a3943dbc1bd43b867def775e41902f987 by Peifeng Yu. Committed on 30/04/2017 at 18:20. Pushed by peifengyu into branch 'master'. Only follow mouse when moved (Fixes Bug #372635) Summary: Use a new variable moved to detect if mouse moved and only change index if the mouse moved. This helps preventing index changes when only using keyboard to search something in milou and to not accidently start/open something you did not want (see bug report https://bugs.kde.org/show_bug.cgi?id=372635 ) In general the onEntered signal seems to be broken in Qt somehow as I could not make it work reliably with Qt 5.7.1. Sometimes it worked but mostly the code using onEntered failed to work with onPositionChanged (I guess this also does not always set it to true). Hence I tried containsMouse which seems to work reliably at least on Qt 5.7.1. Tests are appreciated especially on other Qt versions. Reviewers: broulik, davidedmundson Reviewed By: davidedmundson Subscribers: ltoscano, qi437103, lfurmetz, anthonyfieroni, davidedmundson, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D5490 M +1-0lib/CMakeLists.txt A +40 -0lib/mousehelper.cpp [License: GPL (v2/3)] A +44 -0lib/mousehelper.h [License: GPL (v2/3)] M +12 -4lib/qml/ResultDelegate.qml M +9-0lib/qml/ResultsView.qml M +5-0lib/qml/qmlplugins.cpp https://commits.kde.org/milou/a41a850a3943dbc1bd43b867def775e41902f987 -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 372635] do not follow mousepointer when accessing krunner via keyboard
https://bugs.kde.org/show_bug.cgi?id=372635 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 376595] Kdevelop crashes on watch member variable
https://bugs.kde.org/show_bug.cgi?id=376595 Aetf <7437...@gmail.com> changed: What|Removed |Added Status|VERIFIED|CLOSED --- Comment #27 from Aetf <7437...@gmail.com> --- Thank you for reporting! I've also added a link pointing back to this bug in their bug tracker. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 376595] Kdevelop crashes on watch member variable
https://bugs.kde.org/show_bug.cgi?id=376595 Aetf <7437...@gmail.com> changed: What|Removed |Added Resolution|WAITINGFORINFO |UPSTREAM --- Comment #25 from Aetf <7437...@gmail.com> --- Well adding an UI to set prefix and extra code to identify and match member variable just sounds too much for a workaround for some bug in gdb that will eventually be fixed. For the "info locals", there are also global and static variables that are not member variable. There are too many corner cases, not to even mention single variable is only the simplest case for watchpoint[1]. [1] https://sourceware.org/gdb/onlinedocs/gdb/Set-Watchpoints.html -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 376595] Kdevelop crashes on watch member variable
https://bugs.kde.org/show_bug.cgi?id=376595 Aetf <7437...@gmail.com> changed: What|Removed |Added Attachment #104135|0 |1 is obsolete|| --- Comment #23 from Aetf <7437...@gmail.com> --- Created attachment 104160 --> https://bugs.kde.org/attachment.cgi?id=104160=edit Better handle and report debugger errors Anyway, I've updated my patch to better report and end the debug session in this case. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 376595] Kdevelop crashes on watch member variable
https://bugs.kde.org/show_bug.cgi?id=376595 --- Comment #22 from Aetf <7437...@gmail.com> --- Okay I can reproduce your issue now. I guess the difference is that yours is multi-threaded (several threads for qt internal stuff). And when gdb stopped, it stopped at another thread different from the main thread. Probably gdb can't handle this case well. However I'm afraid there's no much I can do on the kdevelop side. As it's hard to distinguish a member variable from normal ones, and it's unclear whether this is the only condition that would trigger the bug. Maybe you should report this to gdb. In the mean time, as a workaround, you can set watchpoints in the Breakpoints tool view manually, using "this." as the location. This works as intended. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 376595] Kdevelop crashes on watch member variable
https://bugs.kde.org/show_bug.cgi?id=376595
--- Comment #18 from Aetf <7437...@gmail.com> ---
Created attachment 104154
--> https://bugs.kde.org/attachment.cgi?id=104154=edit
GDB outputs when watchpoint goes out of scope
Yes, kdevelop uses plain variable name when adding watch points for member
variables. This however should work because gdb will delete all invalid
watchpoints when the execution left valid scope.
I've created a minimal test program to trigger this problem:
struct testStruct {
int a; int b;
void bar() {
a = a + 1;
}
};
int main() {
testStruct ts;
ts.a = ts.b = 0;
ts.bar();
ts.b++;
return 0;
}
After compile and load it in gdb, this is what I got:
1. break at line 4
2. watch a
3. continue and gdb stopped after a = a + 1 because of watchpoint hit
4. continue again and gdb stopped at some random point after leaving
testStruct::bar() with the following output
Error evaluating expression for watchpoint 2
current stack frame does not contain a variable named `this'
Watchpoint 2 deleted.
5. continue and the program exits normally.
If I use watch this.a instead, the outcome is almost the same with the only
difference being the warning from gdb:
Watchpoint 3 deleted because the program has left the block in
which its expression is valid.
I've attached the full output from gdb. The point here is that gdb should be
able to delete invalid watchpoint gracefully regardless it was set as
"this." or "". And it shouldn't produce malformed output in
its machine interface which kdevelop uses.
That being said, I'm using a newer version of gdb than yours, so probably the
behavior changed. Ian, are you getting the same behavior using my test program?
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 376595] Kdevelop crashes on watch member variable
https://bugs.kde.org/show_bug.cgi?id=376595 --- Comment #16 from Aetf <7437...@gmail.com> --- Created attachment 104135 --> https://bugs.kde.org/attachment.cgi?id=104135=edit Proposed patch -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 376595] Kdevelop crashes on watch member variable
https://bugs.kde.org/show_bug.cgi?id=376595 --- Comment #15 from Aetf <7437...@gmail.com> --- Okay. So setting watch point itself seems normal in log. The crash actually happens before the watch point was triggered. gdb returned two replies for 35-exec-continue command: 35^running and 35^error,msg=\"Command aborted.\" This doesn't confirm to the spec and confused kdevelop which assumes each reply must have a corresponding command. I will fix this by ignoring wild replies from gdb. Please try if my patch fixes the crash. But this is likely also a bug within gdb itself. I would suggest verify if debugging directly in gdb command line works with your program if there's still something wrong. (Probably something like the program doesn't resume execution because the exec-continue command failed) -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 376595] Kdevelop crashes on watch member variable
https://bugs.kde.org/show_bug.cgi?id=376595 --- Comment #12 from Aetf <7437...@gmail.com> --- I see. Seems your Qt version doesn't support semicolon separated logging rules. Instead, create a file named logging.conf with the following content: [Rules] kdevelop.debuggers.gdb.debug=true kdevelop.debuggers.common.debug=true And launch kdevelop with QT_LOGGING_CONF='/path/to/logging.conf' kdevelop I think the crash might be specific to some particular gdb version. But without detailed logging, I can't tell anything yet. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 376595] Kdevelop crashes on watch member variable
https://bugs.kde.org/show_bug.cgi?id=376595 --- Comment #10 from Aetf <7437...@gmail.com> --- Hmm actually I can't reproduce this. I tried with a structure member variable and it works as intended. >From the log output, kdevelop was complaining about gdb not returning required data. So my guessing is something went wrong with either the gdb itself or the way we were setting breakpoints. How do you exactly set break on change? By manually using the gdb console or by hovering on the variable and click "stop on change" button? Also, I'm expecting some log output with the prefix "kdevelop.debuggers.common:" and related to the internal interaction between kdevelop and gdb. Could you paste the full log output? -- You are receiving this mail because: You are watching all bug changes.
[yakuake] [Bug 360037] KF5 yakuake sometimes gets detached and shows up in the task manager
https://bugs.kde.org/show_bug.cgi?id=360037 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 376595] Kdevelop crashes on watch member variable
https://bugs.kde.org/show_bug.cgi?id=376595 Aetf <7437...@gmail.com> changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #8 from Aetf <7437...@gmail.com> --- Hi Ion, from the backtrace it's not clear what's going wrong here. There's no abnormal pointer access in the frame 0 of the backtrace. Could you also provide the console output when crashing? The debugger plugin related logs are disabled by default, you can enable it by starting kdevelop like this inside console: QT_LOGGING_RULES="kdevelop.debuggers.gdb.debug=true;kdevelop.debuggers.common.debug=true" kdevelop -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 374458] Crash when dragging launches in Launch Configuration
https://bugs.kde.org/show_bug.cgi?id=374458 Aetf <7437...@gmail.com> changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Version Fixed In||5.1 -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 374458] Crash when dragging launches in Launch Configuration
https://bugs.kde.org/show_bug.cgi?id=374458 --- Comment #9 from Aetf <7437...@gmail.com> --- Francis could you try https://phabricator.kde.org/D4555 and see if it works for you? -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 374458] Crash when dragging launches in Launch Configuration
https://bugs.kde.org/show_bug.cgi?id=374458 --- Comment #8 from Aetf <7437...@gmail.com> --- Oh I see. Didn't know much about git describe before. ;P Now I can finally reproduce the crash. Launcher items are in fact not draggable. But the crash happens when you click & hold the cursor, then move from a top-level item to its child item, e.g. Debug mode. And it only happens under the following condition: 1. The top-level item must have a child. (Compiled binary, Plasmoid launcher) 2. The child item must be a debug configuration with GDB selected. LLDB won't trigger the crash The crash happens because the code tries to set 'gdb' as launch configuration type on the wrong item. However this is before `LaunchConfiguration::launcherForMode` got called. I don't know how the 'gdb' type string was generated yet. I'm still tracing down the logic when changing pages in the dialog. Will report back with more info later. -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 374458] Crash when dragging launches in Launch Configuration
https://bugs.kde.org/show_bug.cgi?id=374458 --- Comment #5 from Aetf <7437...@gmail.com> --- Hmm, that's weird. I'm on Arch x86_64 too, with qt 5.8.0. And it works normally with today's 5.1 branch HEAD: kdevplatform: 3e2549d39 kdevelop: 2c1a1fd7f6 And in fact I can't find commit gd270016ad or g2c1a1fd7f6 in the repo... >From your version string I guess you used makepkg to build & install? Is there anything special in the PKGBUILD? For sanity check, is there another different version of kdevelop in your system? And just in case, we are talking about the tree view in the "Launch Configurations" dialog which is opened when you click "Run -> Configure Launches...", right? -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 374458] Crash when dragging launches in Launch Configuration
https://bugs.kde.org/show_bug.cgi?id=374458 --- Comment #3 from Aetf <7437...@gmail.com> --- I just tested on the latest 5.1 branch. They are not draggable any more. IMO that makes sense because launches are associated with one project and there's no point to drag them around. Francis, can you reproduce this now? -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 374894] KDevelop crashes when clicking on QuickOpen
https://bugs.kde.org/show_bug.cgi?id=374894 --- Comment #6 from Aetf <7437...@gmail.com> --- (In reply to Aetf from comment #5) > + ed9e1726c, the first bad commit found by git bisect. I can reproduce the > crash somethings s/somethings/sometimes I added some debug log to the itemCount cachedResult method, but the crash happens even before that get called. Looking at the code, in QuickOpenLineEdit::focusInEvent in quickopenplugin.cpp, and only after the QuickOpenWidget is created for the first time, and is set to shown (crash at this line quickopenplugin.cpp:1055). I run out of idea what to looking at next... -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 374894] KDevelop crashes when clicking on QuickOpen
https://bugs.kde.org/show_bug.cgi?id=374894
--- Comment #5 from Aetf <7437...@gmail.com> ---
It's getting weirder. Mainly I tried on three commits (and a few others between
ed9e1726c and 7fa22b617, the results were similar).
+ 2b44ef9f6, the commit right before ed9e1726c. Crash can't be triggered.
+ ed9e1726c, the first bad commit found by git bisect. I can reproduce the
crash somethings
+ 7fa22b617, current master HEAD. Seems it's easier to trigger the crash than
ed9e1726c
By now, the most reliable way for me to trigger the crash is to quickly click
on the line edit right after that main window shows, before the background
parser fully starts.
Here's the relevant log for the crash
kdevplatform.plugins.quickopen: got focus
kdevplatform.plugins.quickopen: old widget QWidget(0x0) force update: false
kdevplatform.plugins.quickopen: created the widget
create expanding tree
kdevplatform.plugins.quickopen: params QSet("Files", "Functions", "Classes",
"Documentation", "Actions") QSet("Project", "Currently Open", "Includes")
kdevplatform.plugins.quickopen: comparing QSet("Currently Open") QSet("Files")
kdevplatform.plugins.quickopen: enabling QSet("Files") QSet("Currently
Open")
kdevplatform.plugins.quickopen: comparing QSet("Project") QSet("Files")
kdevplatform.plugins.quickopen: enabling QSet("Files") QSet("Project")
kdevplatform.plugins.quickopen: comparing QSet("Project") QSet("Functions",
"Classes")
kdevplatform.plugins.quickopen: enabling QSet("Functions", "Classes")
QSet("Project")
kdevplatform.plugins.quickopen: comparing QSet("Includes")
QSet("Documentation")
kdevplatform.plugins.quickopen: enabling QSet("Documentation")
QSet("Includes")
kdevplatform.plugins.quickopen: comparing QSet("Includes") QSet("Actions")
kdevplatform.plugins.quickopen: enabling QSet("Actions") QSet("Includes")
kdevplatform.plugins.quickopen: activating
kdevplatform.plugins.quickopen: eventFilter QChildEvent(ChildAdded,
QObject(0x4b25390))
kdevplatform.plugins.quickopen: eventFilter QChildEvent(ChildAdded,
QObject(0x4b27650))
kdevplatform.plugins.quickopen: before m_widget->show
kdevplatform.plugins.quickopen: eventFilter QEvent(Polish, 0x7ffddd2a19e0)
kdevplatform.plugins.quickopen: eventFilter QEvent(Polish, 0x7ffddd2a19e0)
kdevplatform.plugins.quickopen: eventFilter QChildEvent(ChildPolished,
QWidget(0x37650d0, name = "qt_scrollarea_viewport"))
kdevplatform.plugins.quickopen: eventFilter QChildEvent(ChildPolished,
QWidget(0x2072410, name = "qt_scrollarea_hcontainer"))
kdevplatform.plugins.quickopen: eventFilter QChildEvent(ChildPolished,
QWidget(0x240e860, name = "qt_scrollarea_vcontainer"))
kdevplatform.plugins.quickopen: eventFilter QChildEvent(ChildPolished,
QHeaderView(0x49f7ad0))
kdevplatform.plugins.quickopen: eventFilter QMoveEvent(2,2, non-spontaneous)
kdevplatform.plugins.quickopen: eventFilter QResizeEvent(696, 323,
non-spontaneous)
KCrash: Application 'kdevelop' crashing...
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 374894] KDevelop crashes when clicking on QuickOpen
https://bugs.kde.org/show_bug.cgi?id=374894 --- Comment #3 from Aetf <7437...@gmail.com> --- I did a bisect, seems ed9e1726c8c6c25b601da0893ecff8f9f9f47364 is the first bad commit. Maybe related to the cache of ProjectItemDataProvider::itemCount? Also, sometimes the crash was only triggered when opening a relative big project while background parsing just started running. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 374894] KDevelop crashes when clicking on QuickOpen
https://bugs.kde.org/show_bug.cgi?id=374894 --- Comment #2 from Aetf <7437...@gmail.com> --- I tried to revert 4f3e1fbbc, but it doesn't apply cleanly. There are still compilation errors after solving a few conflicts. So I built the commit before that (f00f30037), and tested. There's no crash. So I can confirm at least the bug was introduced between 4f3e1fbbc...7fa22b617(HEAD). -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 374894] New: KDevelop crashes when clicking on QuickOpen
https://bugs.kde.org/show_bug.cgi?id=374894 Bug ID: 374894 Summary: KDevelop crashes when clicking on QuickOpen Product: kdevelop Version: unspecified Platform: Archlinux Packages OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: 7437...@gmail.com Target Milestone: --- Application: kdevelop (5.1.40) Qt Version: 5.7.1 Frameworks Version: 5.29.0 Operating System: Linux 4.8.13-1-ARCH x86_64 Distribution: "Arch Linux" -- Information about the crash: Using latest git version kdevplatform/kdevelop - What I was doing when the application crashed: * Open KDevelop in a new session * Click on the QuickOpen lineedit on the toolbar * Crash (with or without a project currently open) The crash can be reproduced every time. -- Backtrace: Application: KDevelop (kdevelop), signal: Segmentation fault Using host libthread_db library "/usr/lib/libthread_db.so.1". [Current thread is 1 (Thread 0x7f1ca7373600 (LWP 17089))] Thread 14 (Thread 0x7f1bae4ba700 (LWP 17214)): #0 0x7f1c9db974b8 in pthread_cond_timedwait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7f1ca4865ae6 in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5 #2 0x7f1ca48611e4 in () at /usr/lib/libQt5Core.so.5 #3 0x7f1ca4864cf8 in () at /usr/lib/libQt5Core.so.5 #4 0x7f1c9db91454 in start_thread () at /usr/lib/libpthread.so.0 #5 0x7f1ca417a7df in clone () at /usr/lib/libc.so.6 Thread 13 (Thread 0x7f1baeffd700 (LWP 17212)): #0 0x7f1c9bbc3db0 in g_mutex_lock () at /usr/lib/libglib-2.0.so.0 #1 0x7f1c9bb7e184 in g_main_context_check () at /usr/lib/libglib-2.0.so.0 #2 0x7f1c9bb7e724 in () at /usr/lib/libglib-2.0.so.0 #3 0x7f1c9bb7e89c in g_main_context_iteration () at /usr/lib/libglib-2.0.so.0 #4 0x7f1ca4a942db in QEventDispatcherGlib::processEvents(QFlags) () at /usr/lib/libQt5Core.so.5 #5 0x7f1ca4a3dd3a in QEventLoop::exec(QFlags) () at /usr/lib/libQt5Core.so.5 #6 0x7f1ca4860063 in QThread::exec() () at /usr/lib/libQt5Core.so.5 #7 0x7f1ca4864cf8 in () at /usr/lib/libQt5Core.so.5 #8 0x7f1c9db91454 in start_thread () at /usr/lib/libpthread.so.0 #9 0x7f1ca417a7df in clone () at /usr/lib/libc.so.6 Thread 12 (Thread 0x7f1ba700 (LWP 17199)): #0 0x7f1c9db9710f in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7f1ca4865bab in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5 #2 0x7f1c9900e1c0 in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () at /usr/lib/libKF5ThreadWeaver.so.5 #3 0x7f1c99012988 in () at /usr/lib/libKF5ThreadWeaver.so.5 #4 0x7f1c9900d263 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/libKF5ThreadWeaver.so.5 #5 0x7f1c990101f9 in ThreadWeaver::Thread::run() () at /usr/lib/libKF5ThreadWeaver.so.5 #6 0x7f1ca4864cf8 in () at /usr/lib/libQt5Core.so.5 #7 0x7f1c9db91454 in start_thread () at /usr/lib/libpthread.so.0 #8 0x7f1ca417a7df in clone () at /usr/lib/libc.so.6 Thread 11 (Thread 0x7f1bb4ac1700 (LWP 17198)): #0 0x7f1c9db9710f in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7f1ca4865bab in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5 #2 0x7f1c9900e1c0 in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () at /usr/lib/libKF5ThreadWeaver.so.5 #3 0x7f1c99012988 in () at /usr/lib/libKF5ThreadWeaver.so.5 #4 0x7f1c9900d263 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/libKF5ThreadWeaver.so.5 #5 0x7f1c990101f9 in ThreadWeaver::Thread::run() () at /usr/lib/libKF5ThreadWeaver.so.5 #6 0x7f1ca4864cf8 in () at /usr/lib/libQt5Core.so.5 #7 0x7f1c9db91454 in start_thread () at /usr/lib/libpthread.so.0 #8 0x7f1ca417a7df in clone () at /usr/lib/libc.so.6 Thread 10 (Thread 0x7f1c4bfff700 (LWP 17197)): #0 0x7f1c9db9710f in pthread_cond_wait@@GLIBC_2.3.2 () at /usr/lib/libpthread.so.0 #1 0x7f1ca4865bab in QWaitCondition::wait(QMutex*, unsigned long) () at /usr/lib/libQt5Core.so.5 #2 0x7f1c9900e1c0 in ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*, bool, bool, bool) () at /usr/lib/libKF5ThreadWeaver.so.5 #3 0x7f1c99012988 in () at /usr/lib/libKF5ThreadWeaver.so.5 #4 0x7f1c9900d263 in ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () at /usr/lib/libKF5ThreadWeaver.so.5 #5 0x7f1c990101f9 in ThreadWeaver::Thread::run() () at /usr/lib/libKF5ThreadWeaver.so.5 #6 0x7f1ca4864cf8 in () at /usr/lib/libQt5Core.so.5 #7 0x7f1c9db91454 in start_thread () at
[kdevelop] [Bug 368603] crash when starting an lldb debug session
https://bugs.kde.org/show_bug.cgi?id=368603 --- Comment #22 from Aetf <7437...@gmail.com> --- For a simplest session: $ lldb-mi /path/to/executable -break-insert main.cpp:30 -exec-run There are also commands like -exec-continue, -exec-next. Reference: https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Program-Execution.html#GDB_002fMI-Program-Execution I don't have enough knowledge about how actually a debugger scans app's memory space or the overcommit thing. But my intuition is, just attaching a debugger to the app shouldn't dramatically increases its memory usage... AFAIK, starting a complex app in debugger takes longer simply because the program is being instrumented and thus runs much slower. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 368603] crash when starting an lldb debug session
https://bugs.kde.org/show_bug.cgi?id=368603 Aetf <7437...@gmail.com> changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #20 from Aetf <7437...@gmail.com> --- Pushed to master with commit 262bf5dddf2aef991c66fdc484c58daf32eaa348, so I'm going to close this, reopen it if you have any further problems. A debugger shouldn't take too much memory. It looks like a bug. Did you try to manually debug using lldb 3.9? And please open another report if that only happens in KDevelop. Well, the working directory changing does require another patch[1] ... And I've created a RR in their Phabricator[2], which seems to be more active than their bug tracker. [1] https://llvm.org/bugs/show_bug.cgi?id=30265 [2] https://reviews.llvm.org/D24711 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 368603] crash when starting an lldb debug session
https://bugs.kde.org/show_bug.cgi?id=368603 --- Comment #18 from Aetf <7437...@gmail.com> --- I'm glad you found the reason. So the patch itself works for you now? If so, I'm going to close this and push the change to master. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 368603] crash when starting an lldb debug session
https://bugs.kde.org/show_bug.cgi?id=368603 --- Comment #16 from Aetf <7437...@gmail.com> --- Could you start KDevelop from the console and check the output when starting the debug session on Linux? You can enable debug output from KDevelop by launching it with the command env QT_LOGGING_CONF='logging.conf' kdevelop where the content of logging.conf is [Rules] kdevelop.debuggers.lldb.debug=true kdevelop.debuggers.common.debug=true Also, even if the debug session ends, there should be an output panel titled "Debug" being raised. See if there's any relevant output in that. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 368603] crash when starting an lldb debug session
https://bugs.kde.org/show_bug.cgi?id=368603 Aetf <7437...@gmail.com> changed: What|Removed |Added Attachment #101058|0 |1 is obsolete|| --- Comment #14 from Aetf <7437...@gmail.com> --- Created attachment 101088 --> https://bugs.kde.org/attachment.cgi?id=101088=edit Add propper detection of version string on OS X -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 368603] crash when starting an lldb debug session
https://bugs.kde.org/show_bug.cgi?id=368603 --- Comment #13 from Aetf <7437...@gmail.com> --- Sorry for the delay. I don't have enough time to do any actual coding due to my course work for a few days. That looks good to me. The reason I didn't add the check for OS X was I can't find the mapping between Linux version string and OS X version string. the lldb plugin on Linux didn't work for you after applied my latest patch? Is it the case that you clicked 'don't ask again' and answered no? There should be some output in the Debug output panel saying that session stopped due to unsupported lldb version. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 368603] crash when starting an lldb debug session
https://bugs.kde.org/show_bug.cgi?id=368603 Aetf <7437...@gmail.com> changed: What|Removed |Added Attachment #101057|0 |1 is obsolete|| --- Comment #10 from Aetf <7437...@gmail.com> --- Created attachment 101058 --> https://bugs.kde.org/attachment.cgi?id=101058=edit Add the option "Don't ask again" to warning dialog Okay, here's the one with option "Don't ask again". Currently KDevelop doesn't provide a way to reset these warnings. So you can't change your answer afterwards. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 368603] crash when starting an lldb debug session
https://bugs.kde.org/show_bug.cgi?id=368603 Aetf <7437...@gmail.com> changed: What|Removed |Added Assignee|unassigned-b...@kde.org |7437...@gmail.com Status|NEEDSINFO |ASSIGNED Resolution|WAITINGFORINFO |--- Ever confirmed|0 |1 --- Comment #8 from Aetf <7437...@gmail.com> --- Created attachment 101057 --> https://bugs.kde.org/attachment.cgi?id=101057=edit Fix Bug 268603, warn the user about unsupported lldb version I'm not sure it's a good idea to direct link to liblldb (I'm not aware any major IDE doing that). And building yet another proxy executable from scratch would be reinventing the wheel compared to lldb-mi, which is exactly a proxy already. Anyway, there's the first attempt to fix this bug, the patch does the following: - warn the user about unsupported lldb version - reject user command if an unsupported version is found (to prevent crash on invalid message) Could you try if this works for you? But I have no idea how to make the warning with an option to "Don't show it again". I suppose there should be some library function that I should call. Do you know any warnings shown by KDevelop already has this feature? Maybe I can look at that code to see how to implement this. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 368603] crash when starting an lldb debug session
https://bugs.kde.org/show_bug.cgi?id=368603 --- Comment #9 from Aetf <7437...@gmail.com> --- Oops, it should be Bug 368603 in the description of the attachment. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 368603] crash when starting an lldb debug session
https://bugs.kde.org/show_bug.cgi?id=368603 --- Comment #5 from Aetf <7437...@gmail.com> --- Okay, that patch is required, otherwise lldb-mi doesn't produce correct spec confirming output. That's why handleVersion is getting empty lists. And the version output is quite different, is that what you get on OS X? Seems I still need to find a more robust way to detect lldb version. -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 368603] crash when starting an lldb debug session
https://bugs.kde.org/show_bug.cgi?id=368603 Aetf <7437...@gmail.com> changed: What|Removed |Added Status|UNCONFIRMED |NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #3 from Aetf <7437...@gmail.com> --- The 'version' command is issued after lldb-mi has already been started. And commit 102f673c6ff1afe5b1ca9cb6faa0503663b96e16 was intended to fix the previous way to check version (invoking lldb-mi directly which might not be in path). Strange enough, the output shouldn't be empty. Did you applied this patch? https://llvm.org/bugs/show_bug.cgi?id=28026 Could you do the following and paste the output here? 1. lldb-mi --versionLong 2. lldb-mi and then type version The output should be something like $ lldb-mi --versionLong LLDB Machine Interface Driver (MI) All rights reserved Version: 1.0.0.9 Version: GNU gdb (GDB) 7.4 (This is a MI stub on top of LLDB and not GDB) All rights reserved. $ lldb-mi (gdb) version ~"lldb version 4.0.0 ( http://llvm.org/svn/llvm-project/lldb/trunk revision 279424 clang revision 279424 llvm revision 279424)\n" ^done (gdb) Thank you for trying this out ;) -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 357779] Crash When Debugging [GDBDebugger::DebugSession::interruptDebugger]
https://bugs.kde.org/show_bug.cgi?id=357779 Aetf <7437...@gmail.com> changed: What|Removed |Added Status|CONFIRMED |NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #3 from Aetf <7437...@gmail.com> --- I can't reproduce this with new KDevelop 5 with Qt5. And looking at the code, I have no idea why it would segment fault when calling ::kill(pid, SIGINT); Russell, could you try with the latest KDevelop 5.0.0 and if the bug still exists, upload a test project so that I can reproduce and debug with? -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 368322] Job not fully stopped when starting non-existing debugger executable
https://bugs.kde.org/show_bug.cgi?id=368322 Aetf <7437...@gmail.com> changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Aetf <7437...@gmail.com> --- Fixed in commit b72ece8 -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 368322] Job not fully stopped when starting non-existing debugger executable
https://bugs.kde.org/show_bug.cgi?id=368322 Aetf <7437...@gmail.com> changed: What|Removed |Added Assignee|kdevelop-bugs-n...@kde.org |7437...@gmail.com Status|CONFIRMED |ASSIGNED --- Comment #2 from Aetf <7437...@gmail.com> --- It's due to LLDB plugin uses a different code path for error reporting. Working on a fix now. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 368162] LLDB: Working directory is not changed to the one specified in configuration
https://bugs.kde.org/show_bug.cgi?id=368162 Aetf <7437...@gmail.com> changed: What|Removed |Added Resolution|--- |UPSTREAM Status|UNCONFIRMED |RESOLVED --- Comment #1 from Aetf <7437...@gmail.com> --- Fixed with commit 3bf6698e63a7b65984cb7d0cc87fa764b654ae0e, but won't work unless upstream bug fixed: https://llvm.org/bugs/show_bug.cgi?id=30265 -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 333759] "Variables" tool view sometimes not in sync with Frame Stack view
https://bugs.kde.org/show_bug.cgi?id=333759 Aetf <7437...@gmail.com> changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 333759] "Variables" tool view sometimes not in sync with Frame Stack view
https://bugs.kde.org/show_bug.cgi?id=333759 --- Comment #8 from Aetf <7437...@gmail.com> --- (In reply to Kevin Funk from comment #7) I am still not quite convinced (see below) but maybe the removal deserves it own patch. So, simpler fix submitted to Phabricator. For the "cache/duplicate" thing: I understand that we should avoid updating variables as much as possible due to communication costs. And that's what exactly the *thread_or_frame_changed* event handler for. Is there such a case that this handler is called without an actual change in active thread/frame? Given we now only check cached active thread/frame in this event handler, it looks duplicate to me. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 333759] "Variables" tool view sometimes not in sync with Frame Stack view
https://bugs.kde.org/show_bug.cgi?id=333759
--- Comment #5 from Aetf <7437...@gmail.com> ---
Posted on Phabricator now: https://phabricator.kde.org/D1351
Well, yes, it can be done by just make IVariableController::handleEvent
correctly updates m_active{Frame,Thread} even if
IVariableController::autoUpdate is UpdateNone. No need to touch
IVariableController::setAutoUpdate though.
But I think there is duplication. Maybe my wording isn't clear, but the patch
isn't removing the "only update when active frame/thread chagnes"
functionality, as we only call IVariableController::update when handling
IDebugSession::thread_or_frame_changed event. So no need to do the duplicate
check (The update in IVariableController::setAutoUpdate handles different
situations and is irrelevant here. However, I do wonder if it is needed all the
time)
Besides, m_active{Frame,Thread} only mirror the same value in
FrameStackModel::current{Frame,Thread} and it requires extra effort to keep
them synced. So in my opinion we should remove m_active{Frame,Thread} to
simplify the logic.
I understand removing them breaks binary compatibility. If that's what you are
concerned, then I'm OK to change to the simpler workaround.
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 333759] "Variables" tool view sometimes not in sync with Frame Stack view
https://bugs.kde.org/show_bug.cgi?id=333759 --- Comment #2 from Aetf <7437...@gmail.com> --- Hi, I'm looking into this bug right now. It seems the bug still exists in the latest version. The exact steps to reproduce is as follow: 1. Debug some application 2. Pause the debugger 3. Collapse the variable list or hide the variables tool view 4. Switch to another frame, i.e. frame 1 5. Expand the variable list or show the variables tool view 6. *Important*: switch back to the same frame as in step 2 Actual Results: Variables for frame 1 are shown Expected Results: Variables of the currently selected frame should be shown The reason for this is that internally `IVariableController` keeps track of the current active frame/thread and only updates variables when active frame/thread changes. However, when variables list is hidden, the active frame/thread is not updated. Thus if the user changes frame in this case, the active frame/thread value remains what it was before the variables list is hidden. Then after making variables list visible and changing the frame again to the previous frame, `IVariableController` thinks there is not change at all and skips the update. The attached patch fixes this issue by removing the whole tracking active frame/thread logic. This logic was introduced in 57b2d64f to make sure locals are updated only once. However, with the code evolving, other situations where update might be called with frame/thread unchanged are gone and the above is the only one left, which in fact also doesn't require such logic. Given this tracking logic makes no benefits but bugs only, I removed it in the patch which also fixes the bug. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 333759] "Variables" tool view sometimes not in sync with Frame Stack view
https://bugs.kde.org/show_bug.cgi?id=333759 Aetf <7437...@gmail.com> changed: What|Removed |Added CC||7437...@gmail.com --- Comment #1 from Aetf <7437...@gmail.com> --- Created attachment 98282 --> https://bugs.kde.org/attachment.cgi?id=98282=edit Fix variable toolview not sync with framestack toolview -- You are receiving this mail because: You are watching all bug changes.
