[kdevelop] [Bug 487378] Crash when adding #include statement
https://bugs.kde.org/show_bug.cgi?id=487378 --- Comment #3 from Staffan Palmroos --- Ok, thanks! I have now got crashes in other situations than what I first described, i.e. adding an #include after hibernation. Hibernation likely has nothing to do with it. I did a cursory check on the clang github before but I didn't find anything that directly caught my eye. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 487378] New: Crash when adding #include statement
https://bugs.kde.org/show_bug.cgi?id=487378
Bug ID: 487378
Summary: Crash when adding #include statement
Classification: Applications
Product: kdevelop
Version: unspecified
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: general
Assignee: kdevelop-bugs-n...@kde.org
Reporter: spalmr...@gmail.com
Target Milestone: ---
Application: kdevelop (5.13.240202 (24.02.2))
(Compiled from sources)
Qt Version: 5.15.13
Frameworks Version: 5.115.0
Operating System: Linux 6.6.21-gentoo-radeonsi x86_64
Windowing System: X11
Distribution: "Gentoo Linux"
DrKonqi: 5.27.11 [KCrashBackend]
-- Information about the crash:
KDevelop seems to crash consistently when adding another #include statement to
the source text editor if I have restored the computer (and thus KDevelop) from
hibernation. It doesn't seem to happen anymore after I restart the program or
maybe I just have been lucky to not triggered it in that case.
Now one would reasonably conclude it has something to do with the hibernation
like bad disks or something hardware related but it's particularly consistent
with exactly this situation, adding an #include line to the source code. If it
was a case of bad disks then errors would pop up in various places. in KDevelop
or any other activities I do. This is not the case, my computer is rock stable
otherwise.
Perhaps there is some caching involved in the semantic data structures that
depends on a timeout and when the time suddenly changes, as is the case when
the computer has been hibernated for a while and that somehow gets messed up
when it tries to refresh the cache because of the #include. I don't know how
this all works but it's a theory.
The crash can be reproduced sometimes.
-- Backtrace:
Application: KDevelop (kdevelop), signal: Segmentation fault
Content of s_kcrashErrorMessage: std::unique_ptr = {get() = 0x0}
[KCrash Handler]
#6 0x7fbfcf4135d9 in clang::ASTReader::ReadSLocEntry (this=0x7fbed7436cf0,
ID=-84672) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/lib/Serialization/ASTReader.cpp:1497
#7 0x7fbfce424099 in clang::SourceManager::loadSLocEntry
(this=0x7fbfe3e757a0, Index=84670, Invalid=0x0) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/lib/Basic/SourceManager.cpp:435
#8 0x7fbfce424521 in clang::SourceManager::getLoadedSLocEntry
(Invalid=0x0, Index=84670, this=) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/include/clang/Basic/SourceManager.h:1718
#9 clang::SourceManager::getLoadedSLocEntryByID (Invalid=0x0, ID=-84672,
this=) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/include/clang/Basic/SourceManager.h:1822
#10 clang::SourceManager::getSLocEntryByID (Invalid=0x0, ID=-84672,
this=) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/include/clang/Basic/SourceManager.h:1816
#11 clang::SourceManager::isOffsetInFileID (this=, FID=...,
SLocOffset=2131236458) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/include/clang/Basic/SourceManager.h:1866
#12 0x7fbfce4248a9 in clang::SourceManager::getFileIDLoaded
(this=this@entry=0x7fbfe3e757a0, SLocOffset=SLocOffset@entry=2131236458) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/include/clang/Basic/SourceLocation.h:65
#13 0x7fbfce425e62 in clang::SourceManager::getFileIDLoaded
(SLocOffset=2131236458, this=0x7fbfe3e757a0) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/lib/Basic/SourceManager.cpp:867
#14 clang::SourceManager::getFileIDSlow (SLocOffset=2131236458,
this=0x7fbfe3e757a0) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/lib/Basic/SourceManager.cpp:779
#15 clang::SourceManager::getFileIDSlow (SLocOffset=2131236458,
this=0x7fbfe3e757a0) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/lib/Basic/SourceManager.cpp:771
#16 clang::SourceManager::getFileID (SLocOffset=2131236458,
this=0x7fbfe3e757a0) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/include/clang/Basic/SourceManager.h:1830
#17 clang::SourceManager::getFileID (SpellingLoc=..., this=0x7fbfe3e757a0) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/include/clang/Basic/SourceManager.h:1119
#18 clang::SourceManager::getDecomposedExpansionLoc (this=0x7fbfe3e757a0,
Loc=...) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/include/clang/Basic/SourceManager.h:1259
#19 0x7fbfce427784 in clang::SourceManager::getFileCharacteristic
(this=this@entry=0x7fbfe3e757a0, Loc=..., Loc@entry=...) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/lib/Basic/SourceManager.cpp:1477
#20 0x7fbfcdf5ce39 in clang::SourceManager::isInSystemHeader (Loc=...,
this=0x7fbfe3e757a0) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/include/clang/Basic/SourceManager.h:1509
#21 clang_Location_isInSystemHeader (location=...) at
/usr/src/debug/sys-devel/clang-17.0.6/clang/tools/libclang/CXSourceLocation.cpp:209
#22 0x7fbfed33821a in (anonymous namespace)::declVisitor (cursor=...,
parent=..., d=0x7fbfed2fe470
[kdevelop] [Bug 327193] "Classes" tool view not updated when renaming a class.
https://bugs.kde.org/show_bug.cgi?id=327193 Staffan Palmroos changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED --- Comment #4 from Staffan Palmroos --- Indeed I can reproduce it with KDevelop Version 5.9.220803 (22.08.3) I do this by opening the classes view, double click a class name in the view to open the header file for the class. I then right click on the class definition to rename the class. The class is renamed together with all the references to it but the classes tool view is not updated. Now I can no longer click on the class name to open the header file. However, in the source code editor I now get a suggestion to rename the file to reflect the class name. When I do so the program crashed but I guess that's another bug. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376859] Tag Shortcut Key Combination Conflict Dialog Always Appears
https://bugs.kde.org/show_bug.cgi?id=376859 --- Comment #22 from Staffan --- (In reply to Maik Qualmann from comment #21) > Neither F1 nor F10 is assigned to the manual in the digiKam default > settings. This is probably an automatic assignment in your desktop operating > system. > > Maik That does indeed seem to be the case. Thanks! -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376859] Tag Shortcut Key Combination Conflict Dialog Always Appears
https://bugs.kde.org/show_bug.cgi?id=376859 --- Comment #20 from Staffan --- (In reply to Staffan from comment #18) > I have the same, or at least a similar, problem using digiKam 7.6. It was > also present in 7.4 and 7.5 but I didn't report it then, assuming that it > would be fixed in the next version. > > I had assigned the F1 key to 'Pick label "Rejected"' which was reported to > be in conflict with 'digiKam Handbook'. When removing the assignment, > digiKam starts up without displaying the error messages. However, the F1 key > does not seem to do anything. Under 'Help', I see that the 'Online Handbook' > (is that the same as the 'digiKam Handbook'?) is assigned to F10 and this > key (F10) does indeed bring up 'Revision 7.0' of the handbook. But the > disputed F1 key does nothing (that I can see) and I haven't been able to > determine that it is actually assigned to the handbook, i.e. I haven't found > the place where that assignment is done. > > I have a screendump named digiKam_bug_376859.png which I'll try to attach. I might add that I'm using the digiKam-7.6.0-x86-64.appimage on Linux; currently Linux Mint 20.3 (previous versions 7.5 and 7.4 on Linux Mint 20.2). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376859] Tag Shortcut Key Combination Conflict Dialog Always Appears
https://bugs.kde.org/show_bug.cgi?id=376859 Staffan changed: What|Removed |Added Attachment #140006|0 |1 is obsolete|| --- Comment #19 from Staffan --- Created attachment 148497 --> https://bugs.kde.org/attachment.cgi?id=148497&action=edit The bug is still present in digiKam 7.6 I had assigned the F1 key to 'Pick label "Rejected"' which was reported to be in conflict with 'digiKam Handbook'. When removing the assignment, digiKam starts up without displaying the error messages. However, the F1 key does not seem to do anything as far as I can see. Under 'Help', I see that the 'Online Handbook' (is that the same as the 'digiKam Handbook'?) is assigned to F10 and this key (F10) does indeed bring up 'Revision 7.0' of the handbook. But the disputed F1 key does nothing... -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 376859] Tag Shortcut Key Combination Conflict Dialog Always Appears
https://bugs.kde.org/show_bug.cgi?id=376859 Staffan changed: What|Removed |Added CC||staf...@sgsresa.se --- Comment #18 from Staffan --- I have the same, or at least a similar, problem using digiKam 7.6. It was also present in 7.4 and 7.5 but I didn't report it then, assuming that it would be fixed in the next version. I had assigned the F1 key to 'Pick label "Rejected"' which was reported to be in conflict with 'digiKam Handbook'. When removing the assignment, digiKam starts up without displaying the error messages. However, the F1 key does not seem to do anything. Under 'Help', I see that the 'Online Handbook' (is that the same as the 'digiKam Handbook'?) is assigned to F10 and this key (F10) does indeed bring up 'Revision 7.0' of the handbook. But the disputed F1 key does nothing (that I can see) and I haven't been able to determine that it is actually assigned to the handbook, i.e. I haven't found the place where that assignment is done. I have a screendump named digiKam_bug_376859.png which I'll try to attach. -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 424298] valgrind 3.16.1: vex amd64->IR: unhandled instruction bytes: 0xF 0xC7 0xF8 0x89 0x4 0x24 0xF 0x82 0x63 0x1
https://bugs.kde.org/show_bug.cgi?id=424298 --- Comment #1 from Staffan --- Created attachment 130183 --> https://bugs.kde.org/attachment.cgi?id=130183&action=edit The source code and Makefile for reproduction of the error -- You are receiving this mail because: You are watching all bug changes.
[valgrind] [Bug 424298] New: valgrind 3.16.1: vex amd64->IR: unhandled instruction bytes: 0xF 0xC7 0xF8 0x89 0x4 0x24 0xF 0x82 0x63 0x1
https://bugs.kde.org/show_bug.cgi?id=424298 Bug ID: 424298 Summary: valgrind 3.16.1: vex amd64->IR: unhandled instruction bytes: 0xF 0xC7 0xF8 0x89 0x4 0x24 0xF 0x82 0x63 0x1 Product: valgrind Version: unspecified Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: vex Assignee: jsew...@acm.org Reporter: staffan...@gmail.com Target Milestone: --- Created attachment 130181 --> https://bugs.kde.org/attachment.cgi?id=130181&action=edit The script build_dpdk.sh installs and builds DPDK 19.11 SUMMARY When using valgrind 3.16.1 on an application using DPDK libraries, the following run-time error is encountered: vex amd64->IR: unhandled instruction bytes: 0xF 0xC7 0xF8 0x89 0x4 0x24 0xF 0x82 0x63 0x1 STEPS TO REPRODUCE 1. Install DPDK 19.11 and set the environment variable RTE_SDK to point to the directory where DPDK 19.11 is installed. This can be accomplished by executing the attached script build_dpdk.sh. 2. Untar the attached filed Test_Valgrind.tar 3. cd Test_Valgrind 4. make 5. valgrind ./mla_test OBSERVED RESULT epkswid@elx783742wq:~/Test_Valgrind$ ~/Downloads/valgrind-3.16.1/bin/bin/valgrind ./mla_test ==23290== Memcheck, a memory error detector ==23290== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==23290== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright info ==23290== Command: ./mla_test ==23290== vex amd64->IR: unhandled instruction bytes: 0xF 0xC7 0xF8 0x89 0x4 0x24 0xF 0x82 0x63 0x1 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=0F vex amd64->IR: PFX.66=0 PFX.F2=0 PFX.F3=0 ==23290== valgrind: Unrecognised instruction at address 0x10c254. ==23290==at 0x10C254: rte_rand_init (in /home/epkswid/Test_Valgrind/mla_test) ==23290==by 0x13C0EC: __libc_csu_init (in /home/epkswid/Test_Valgrind/mla_test) ==23290==by 0x548CB27: (below main) (libc-start.c:266) EXPECTED RESULT No unhandled instructions should occur when executing valgrind. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION valgrind 3.16.1 epkswid@elx783742wq:~/Test_Valgrind$ uname -a Linux elx783742wq 4.15.0-109-generic #110-Ubuntu SMP Tue Jun 23 02:39:32 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux epkswid@elx783742wq:~/Test_Valgrind$ cat /etc/*-release DISTRIB_ID=Ubuntu DISTRIB_RELEASE=18.04 DISTRIB_CODENAME=bionic DISTRIB_DESCRIPTION="Ubuntu 18.04.4 LTS" NAME="Ubuntu" VERSION="18.04.4 LTS (Bionic Beaver)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 18.04.4 LTS" VERSION_ID="18.04" HOME_URL="https://www.ubuntu.com/"; SUPPORT_URL="https://help.ubuntu.com/"; BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"; PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"; VERSION_CODENAME=bionic UBUNTU_CODENAME=bionic epkswid@elx783742wq:~/Test_Valgrind$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) epkswid@elx783742wq:~/Test_Valgrind$ When the executable file mla_test is executed without valgrind, the following is printed: epkswid@elx783742wq:~/Test_Valgrind$ ./mla_test MEMPOOL: Cannot allocate tailq entry! epkswid@elx783742wq:~/Test_Valgrind$ There is thus no crash although there is an error message printed. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 389424] New: [Wish] Give a hint to the debugger how you want to view a variable and custom views
https://bugs.kde.org/show_bug.cgi?id=389424
Bug ID: 389424
Summary: [Wish] Give a hint to the debugger how you want to
view a variable and custom views
Product: kdevelop
Version: 5.2.1
Platform: Gentoo Packages
OS: Linux
Status: UNCONFIRMED
Severity: wishlist
Priority: NOR
Component: CPP Debugger
Assignee: kdevelop-bugs-n...@kde.org
Reporter: spalmr...@gmail.com
CC: niko.s...@gmail.com
Target Milestone: ---
I think it would be useful if I could put a hint in my code how I want to view
a variable in the debugger instead of having to manually change it every time I
debug.
Something like:
int func() {
// Show this variable as 'hex' by default
/// kdbg(format:hex)
int a1 = 0x20;
// Show this variable as 'binary' by default, filling the left side with
0's
/// kdbg(format:bin,fill:'0')
int a2 = 127;
// Show this float variable with no exponent but with 9 significant digits
/// kdbg(notation:noexp,digits:9)
float a3 = 0.04;
...
}
I've added a couple other bits of functionality here too such as 0-filling and
different formats for float variables. This can be ignored of course.
Expanding this a bit more, I would like to be able to write custom views of
variables in the debugger, for example being able to view matrices in an actual
matrix view. Then this notification mechanism could be used to tell the
debugger when to use this custom view. Example:
#include
void render() {
/// kdbg(format:glm-matrix4)
glm::mat4 projection = GetProjectionMatrix();
/// kdbg(format:glm-vec3)
glm::vec3 direction = GetDirection();
...
}
--
You are receiving this mail because:
You are watching all bug changes.
[kdevelop] [Bug 389421] New: "Projects" view is filled with CMake meta-targets
https://bugs.kde.org/show_bug.cgi?id=389421 Bug ID: 389421 Summary: "Projects" view is filled with CMake meta-targets Product: kdevelop Version: 5.2.1 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: kdevelop-bugs-n...@kde.org Reporter: spalmr...@gmail.com Target Milestone: --- Created attachment 110117 --> https://bugs.kde.org/attachment.cgi?id=110117&action=edit CMake meta-targets in projects view Since KDevelop 5.2(.1?) the "Projects" view is filled upp with CMake meta-targets such as "edit_cache" "install", "install/local", "install/strip", "list_install_components" and "rebuild_cache". They are replicated in every directory in the project tree. These are not very useful in my opinion and occupy valuable screen estate for no good reason. It is also not possible to get rid of them with the "Exclude item from project" option since that only applies to files and folders, not meta-objects. KDevelop 5.1.2 did not have this behaviour. I'm not sure if this is a new "feature" or a regression but I would like to get rid of them somehow. Attached is a screenshot of a completely fresh project. It's my own project template but it does the same if I use the built-in "Standard/Terminal" template but that doesn't have multiple directories. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 387748] Regression: Kdevelop no longer parses/renders doxygen (javadoc) comments
https://bugs.kde.org/show_bug.cgi?id=387748 --- Comment #1 from Staffan Palmroos --- Created attachment 109277 --> https://bugs.kde.org/attachment.cgi?id=109277&action=edit The exact same code in Kdevelop 5.1.1 formatted and rendered properly in the tooltip -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 387748] New: Regression: Kdevelop no longer parses/renders doxygen (javadoc) comments
https://bugs.kde.org/show_bug.cgi?id=387748 Bug ID: 387748 Summary: Regression: Kdevelop no longer parses/renders doxygen (javadoc) comments Product: kdevelop Version: 5.2.1 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Documentation viewer Assignee: kdevelop-bugs-n...@kde.org Reporter: spalmr...@gmail.com Target Milestone: --- Created attachment 109276 --> https://bugs.kde.org/attachment.cgi?id=109276&action=edit Unparsed doxygen comment in the tooltip. In Kdevelop 5.1.1 doxygen comments were parsed and properly rendered in the tooltips when hovering over your types (See pictures). In version 5.2.1 it just shows the raw text without formatting, which is a regression -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 385113] Turn off semantic analysis for GLSL (or fix it)
https://bugs.kde.org/show_bug.cgi?id=385113 --- Comment #3 from Staffan Palmroos --- Created attachment 108064 --> https://bugs.kde.org/attachment.cgi?id=108064&action=edit Screenshot of the problem Here is a screenshot of it. The Problem tab is full of errors because it parses it as C(++) code when it isn't. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 385113] Turn off semantic analysis for GLSL (or fix it)
https://bugs.kde.org/show_bug.cgi?id=385113 --- Comment #2 from Staffan Palmroos --- Created attachment 108063 --> https://bugs.kde.org/attachment.cgi?id=108063&action=edit Test project for GLSL parsing issues Sure, here's one. It's not a complete program, just some vertex and fragment shaders that triggers the problem mentioned. -- You are receiving this mail because: You are watching all bug changes.
[kdevelop] [Bug 385113] New: Turn off semantic analysis for GLSL (or fix it)
https://bugs.kde.org/show_bug.cgi?id=385113 Bug ID: 385113 Summary: Turn off semantic analysis for GLSL (or fix it) Product: kdevelop Version: unspecified Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Problem reporter Assignee: kdevelop-bugs-n...@kde.org Reporter: spalmr...@gmail.com Target Milestone: --- The semantic analysis in KDevelop is great when it works but unfortunately it doesn't for GLSL code, which means it thinks more or less every line is incorrect and it keeps throwing tons of popups in my face. This is driving me up the wall and I can't find a way to turn it off for GLSL files. So basically I'd like some way of forcing it off for specific file types. Even better would be if it could actually handle GLSL code but I realize that would require quite a bit more effort so at least turning it off would be good. Typical file endings for GLSL code is *.glsl *.vert *.frag, *.vs *.fs and probably a couple more for other types of shaders. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 374002] New: kwin_x11 crash every time I login
https://bugs.kde.org/show_bug.cgi?id=374002 Bug ID: 374002 Summary: kwin_x11 crash every time I login Product: kwin Version: 5.8.3 Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: spalmr...@gmail.com Target Milestone: --- Application: kwin_x11 (5.8.3) (Compiled from sources) Qt Version: 5.6.2 Frameworks Version: 5.26.0 Operating System: Linux 4.8.15-gentoo x86_64 Distribution (Platform): Gentoo Packages -- Information about the crash: - What I was doing when the application crashed: Logging in to KDE crashes kwin_x11 every time. I think this is related to bug #361236 but DrKonqi doesn't seem to allow me to add to that report. I just wanted to upload my backtrace in case it's helpful. The crash can be reproduced every time. -- Backtrace: Application: KWin (kwin_x11), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". 84 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS) [Current thread is 1 (Thread 0x7f3de80e1800 (LWP 3882))] Thread 5 (Thread 0x7f3dd0b7b700 (LWP 3923)): #0 0x7f3de79d7243 in select () at ../sysdeps/unix/syscall-template.S:84 #1 0x7f3de58bb246 in qt_safe_select (nfds=8, fdread=fdread@entry=0x7f3dc4000a78, fdwrite=fdwrite@entry=0x7f3dc4000d08, fdexcept=fdexcept@entry=0x7f3dc4000f98, orig_timeout=orig_timeout@entry=0x0) at kernel/qcore_unix.cpp:65 #2 0x7f3de58bc9f2 in QEventDispatcherUNIX::select (timeout=0x0, exceptfds=0x7f3dc4000f98, writefds=0x7f3dc4000d08, readfds=0x7f3dc4000a78, nfds=, this=0x7f3dc40008c0) at kernel/qeventdispatcher_unix.cpp:320 #3 QEventDispatcherUNIXPrivate::doSelect (this=this@entry=0x7f3dc40008e0, flags=..., flags@entry=..., timeout=timeout@entry=0x0) at kernel/qeventdispatcher_unix.cpp:196 #4 0x7f3de58bcfa4 in QEventDispatcherUNIX::processEvents (this=0x7f3dc40008c0, flags=...) at kernel/qeventdispatcher_unix.cpp:607 #5 0x7f3de586f53a in QEventLoop::exec (this=this@entry=0x7f3dd0b7ad70, flags=..., flags@entry=...) at kernel/qeventloop.cpp:206 #6 0x7f3de56bd9bd in QThread::exec (this=this@entry=0x7f3de8268580 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread.cpp:500 #7 0x7f3de81fa276 in QDBusConnectionManager::run (this=0x7f3de8268580 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at qdbusconnection.cpp:189 #8 0x7f3de56c2323 in QThreadPrivate::start (arg=0x7f3de8268580 <(anonymous namespace)::Q_QGS__q_manager::innerFunction()::holder>) at thread/qthread_unix.cpp:365 #9 0x7f3de7c974e0 in start_thread (arg=0x7f3dd0b7b700) at pthread_create.c:334 #10 0x7f3de79de82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 4 (Thread 0x7f3dc9ea5700 (LWP 3947)): #0 0x7f3de79d7243 in select () at ../sysdeps/unix/syscall-template.S:84 #1 0x7f3de58bb246 in qt_safe_select (nfds=13, fdread=fdread@entry=0x7f3db8000a78, fdwrite=fdwrite@entry=0x7f3db8000d08, fdexcept=fdexcept@entry=0x7f3db8000f98, orig_timeout=orig_timeout@entry=0x0) at kernel/qcore_unix.cpp:65 #2 0x7f3de58bc9f2 in QEventDispatcherUNIX::select (timeout=0x0, exceptfds=0x7f3db8000f98, writefds=0x7f3db8000d08, readfds=0x7f3db8000a78, nfds=, this=0x7f3db80008c0) at kernel/qeventdispatcher_unix.cpp:320 #3 QEventDispatcherUNIXPrivate::doSelect (this=this@entry=0x7f3db80008e0, flags=..., flags@entry=..., timeout=timeout@entry=0x0) at kernel/qeventdispatcher_unix.cpp:196 #4 0x7f3de58bcfa4 in QEventDispatcherUNIX::processEvents (this=0x7f3db80008c0, flags=...) at kernel/qeventdispatcher_unix.cpp:607 #5 0x7f3de586f53a in QEventLoop::exec (this=this@entry=0x7f3dc9ea4d80, flags=..., flags@entry=...) at kernel/qeventloop.cpp:206 #6 0x7f3de56bd9bd in QThread::exec (this=this@entry=0x1e34090) at thread/qthread.cpp:500 #7 0x7f3de0878ca6 in QQmlThreadPrivate::run (this=0x1e34090) at qml/ftw/qqmlthread.cpp:141 #8 0x7f3de56c2323 in QThreadPrivate::start (arg=0x1e34090) at thread/qthread_unix.cpp:365 #9 0x7f3de7c974e0 in start_thread (arg=0x7f3dc9ea5700) at pthread_create.c:334 #10 0x7f3de79de82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 3 (Thread 0x7f3dc8dec700 (LWP 3995)): #0 pthread_cond_wait () at ../sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x7f3de4a77f65 in QTWTF::TCMalloc_PageHeap::scavengerThread (this=0x7f3de4b61e40 ) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:2359 #2 0x7f3de4a77fa9 in QTWTF::TCMalloc_PageHeap::runScavengerThread (context=) at ../3rdparty/javascriptcore/JavaScriptCore/wtf/FastMalloc.cpp:1464 #3 0x7f3de7c974e0 in start_thread (arg=0x7f3dc8dec700) at pthread_create.c:334 #4 0x7f3de79de82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Threa
[okteta] [Bug 371800] Automatically adjust the headers in the structures view (w/ patches)
https://bugs.kde.org/show_bug.cgi?id=371800 --- Comment #3 from Staffan Palmroos --- True, it might be unnecessary to have a setting for it. On the other hand, there might be a situation where some name or type string is very long or very indented pushing the value column very far to the right. It could then be annoying to not be able to make the other columns narrower. Anyway, I forgot a small piece in the last patch apparently, the entry in the .kcfg file. I've attached a patch for it should you want to use it. -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 371800] Automatically adjust the headers in the structures view (w/ patches)
https://bugs.kde.org/show_bug.cgi?id=371800 --- Comment #2 from Staffan Palmroos --- Created attachment 101985 --> https://bugs.kde.org/attachment.cgi?id=101985&action=edit Missing entry in the .kcfg file for the automatic width adjustment -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 371800] New: Automatically adjust the headers in the structures view (w/ patches)
https://bugs.kde.org/show_bug.cgi?id=371800 Bug ID: 371800 Summary: Automatically adjust the headers in the structures view (w/ patches) Product: okteta Version: unspecified Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Structures Tool Assignee: arichardson@gmail.com Reporter: spalmr...@gmail.com CC: kosse...@kde.org Target Milestone: --- Created attachment 101866 --> https://bugs.kde.org/attachment.cgi?id=101866&action=edit patch: automatically adjust the width of the view headers I've been using the structures tool quite a lot recently and one thing that has annoyed me is that I had to constantly adjust the width of the headers to see the information properly. So I dug around a little bit and I managed to fix the problem myself. The QViewHeaders class has a mode for automatically adjust the headers so I added a checkbox to the Settings window to allow the user to switch between automatically adjusting the widths or doing it manually. It's just a small problem, I couldn't figure out how to make the settings dialog window bigger so the checkbox is actually outside of view by default, you need to enlarge the window manually to see it. I'm sure someone better versed in Qt coding than me can figure out how to do this. I'm attaching my patches to this report. -- You are receiving this mail because: You are watching all bug changes.
[okteta] [Bug 371790] New: Increase array limit >10000
https://bugs.kde.org/show_bug.cgi?id=371790 Bug ID: 371790 Summary: Increase array limit >1 Product: okteta Version: unspecified Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: Structures Tool Assignee: arichardson@gmail.com Reporter: spalmr...@gmail.com CC: kosse...@kde.org Target Milestone: --- Created attachment 101855 --> https://bugs.kde.org/attachment.cgi?id=101855&action=edit Increase the element limit of arrays to 65535 Hi Is there a particular reason why there is a 1 elements limit on arrays in the structures tool? It's a great tool and I've recently used it for investigating 3d object files from a game. When looking at arrays of vertices I often reach the limit of 1 elements so I downloaded the Okteta source and increased this limit to 65535 and the program seems to work just fine. So, if there's no particular reason for this limit I suggest that it be increased, it's just one line in kasten/controllers/view/structures/datatypes/array/arraydatainformation.h: static const uint MAX_LEN = 1; I've attached a patch if you want it. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 366787] Desktop settings add folder dialog wants to rename folders when clicking them.
https://bugs.kde.org/show_bug.cgi?id=366787 --- Comment #1 from Staffan Palmroos --- Addendum: Aha! I just found out why this happens. I have "Double-click to open files and folders" enabled in Mouse Controls (Desktop Settings). This interferes with the behavior of the Add Folder dialog. So if I change to "Single-click to open files and folders" the dialog works as expected. Apparently the rename mechanism has priority over the open folder mechanism. However, I want to have the double-click function in other places so I don't want to switch. Is it possible to fix it so that the double-click-to-rename mechanism is disabled if the "Double-click to open files and folders" is enabled? You can still rename folders using the F2 key if that is really what you want. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 366787] New: Desktop settings add folder dialog wants to rename folders when clicking them.
https://bugs.kde.org/show_bug.cgi?id=366787 Bug ID: 366787 Summary: Desktop settings add folder dialog wants to rename folders when clicking them. Product: systemsettings Version: 5.6.5 Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: spalmr...@gmail.com I don't really know where to file this bug so I hope someone will move it to the right place. It's about settings so this should be close at least. Also, I don't really know what exact version of KDE this is supposed to be. The version numbers doesn't make sense to me. According to the Gentoo package system I'm running version 15.12.3, Kate claims I'm running KDE Frameworks 5.23.0 and another bug I filed yesterday with Dr Konqi says 5.6.5 so I guess that's it. It's very confusing! Most programs don't actually say what version it's running, they used to do that in the 'about' window but not anymore apparently. Whatever is marked as stable on Gentoo as of right now is what I'm running :) Anyway, here's the bug report: 1. Right click on the desktop and select "Desktop Settings". Set "Wallpaper Type" to Slideshow. 2. You now have to add one or more folders with wallpapers. By the way, this should be preset to the standard wallpaper path (/usr/share/wallpapers). 3. Click the Add Folders to get a dialog to select the folder. Now, in this dialog if you click on the name of a folder to expand it it doesn't actually expand instead it expects you to rename it. You have to click the small ">" button to expand it. Surely this cannot be intentional, it is extremely unlikely that the user would want to rename a folder in this situation. The default action should be to expand the folder of course. Reproducible: Always -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 366761] New: Crash when selecting the Plastik window decoration
https://bugs.kde.org/show_bug.cgi?id=366761 Bug ID: 366761 Summary: Crash when selecting the Plastik window decoration Product: kwin Version: 5.6.5 Platform: Compiled Sources OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: spalmr...@gmail.com Application: kwin_x11 (5.6.5) (Compiled from sources) Qt Version: 5.6.1 Frameworks Version: 5.23.0 Operating System: Linux 4.4.6-gentoo x86_64 Distribution (Platform): Gentoo Packages -- Information about the crash: - What I was doing when the application crashed: In system settings -> Window Decorations, I switched to the Plastik window theme and clicked "Apply". KWin crashed but then started up again with the Plastik theme. The crash can be reproduced every time. -- Backtrace: Application: KWin (kwin_x11), signal: Segmentation fault Using host libthread_db library "/lib64/libthread_db.so.1". [Current thread is 1 (Thread 0x7f74b26c1800 (LWP 10696))] Thread 6 (Thread 0x7f749e002700 (LWP 10699)): #0 0x7f74b1f855fd in poll () from /lib64/libc.so.6 #1 0x7f74b036ab12 in poll (__timeout=-1, __nfds=1, __fds=0x7f749e001cc0) at /usr/include/bits/poll2.h:46 #2 _xcb_conn_wait (c=c@entry=0x1702d30, cond=cond@entry=0x1702d70, vector=vector@entry=0x0, count=count@entry=0x0) at /usr/src/debug/x11-libs/libxcb-1.11.1/libxcb-1.11.1/src/xcb_conn.c:459 #3 0x7f74b036c8ef in xcb_wait_for_event (c=0x1702d30) at /usr/src/debug/x11-libs/libxcb-1.11.1/libxcb-1.11.1/src/xcb_in.c:693 #4 0x7f749eaaf029 in QXcbEventReader::run() () from /usr/lib64/libQt5XcbQpa.so.5 #5 0x7f74b062b95c in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5 #6 0x7f74b2249494 in start_thread () from /lib64/libpthread.so.0 #7 0x7f74b1f8e5dd in clone () from /lib64/libc.so.6 Thread 5 (Thread 0x7f74973eb700 (LWP 10701)): #0 0x7f74b1f872f3 in select () from /lib64/libc.so.6 #1 0x7f74b08163b1 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib64/libQt5Core.so.5 #2 0x7f74b0817a9e in QEventDispatcherUNIXPrivate::doSelect(QFlags, timespec*) () from /usr/lib64/libQt5Core.so.5 #3 0x7f74b0817fdd in QEventDispatcherUNIX::processEvents(QFlags) () from /usr/lib64/libQt5Core.so.5 #4 0x7f74b07cc5ba in QEventLoop::exec(QFlags) () from /usr/lib64/libQt5Core.so.5 #5 0x7f74b0627204 in QThread::exec() () from /usr/lib64/libQt5Core.so.5 #6 0x7f74b27d3235 in QDBusConnectionManager::run() () from /usr/lib64/libQt5DBus.so.5 #7 0x7f74b062b95c in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5 #8 0x7f74b2249494 in start_thread () from /lib64/libpthread.so.0 #9 0x7f74b1f8e5dd in clone () from /lib64/libc.so.6 Thread 4 (Thread 0x7f748710f700 (LWP 10705)): #0 0x7f74b0817be6 in QEventDispatcherUNIXPrivate::doSelect(QFlags, timespec*) () from /usr/lib64/libQt5Core.so.5 #1 0x7f74b0817fdd in QEventDispatcherUNIX::processEvents(QFlags) () from /usr/lib64/libQt5Core.so.5 #2 0x7f74b07cc5ba in QEventLoop::exec(QFlags) () from /usr/lib64/libQt5Core.so.5 #3 0x7f74b0627204 in QThread::exec() () from /usr/lib64/libQt5Core.so.5 #4 0x7f74aac8fa25 in QQmlThreadPrivate::run() () from /usr/lib64/libQt5Qml.so.5 #5 0x7f74b062b95c in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5 #6 0x7f74b2249494 in start_thread () from /lib64/libpthread.so.0 #7 0x7f74b1f8e5dd in clone () from /lib64/libc.so.6 Thread 3 (Thread 0x7f7486086700 (LWP 10706)): #0 0x7f74b224f0bf in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0 #1 0x7f74af7c0264 in QTWTF::TCMalloc_PageHeap::scavengerThread() () from /usr/lib64/libQt5Script.so.5 #2 0x7f74af7c02a9 in QTWTF::TCMalloc_PageHeap::runScavengerThread(void*) () from /usr/lib64/libQt5Script.so.5 #3 0x7f74b2249494 in start_thread () from /lib64/libpthread.so.0 #4 0x7f74b1f8e5dd in clone () from /lib64/libc.so.6 Thread 2 (Thread 0x7f7494ca1700 (LWP 10736)): #0 0x7f74b1f872f3 in select () from /lib64/libc.so.6 #1 0x7f74b08163b1 in qt_safe_select(int, fd_set*, fd_set*, fd_set*, timespec const*) () from /usr/lib64/libQt5Core.so.5 #2 0x7f74b0817a9e in QEventDispatcherUNIXPrivate::doSelect(QFlags, timespec*) () from /usr/lib64/libQt5Core.so.5 #3 0x7f74b0817fdd in QEventDispatcherUNIX::processEvents(QFlags) () from /usr/lib64/libQt5Core.so.5 #4 0x7f74b07cc5ba in QEventLoop::exec(QFlags) () from /usr/lib64/libQt5Core.so.5 #5 0x7f74b0627204 in QThread::exec() () from /usr/lib64/libQt5Core.so.5 #6 0x7f74aac8fa25 in QQmlThreadPrivate::run() () from /usr/lib64/libQt5Qml.so.5 #7 0x7f74b062b95c in QThreadPrivate::start(void*) () from /usr/lib64/libQt5Core.so.5 #8 0x7f74b2249494 in start_thread () from /lib64/libpthread.so.0 #9 0x7f74b
