[kdevelop] [Bug 368555] New: KDevelop crashes when you attempt to "Kill All Jobs" when no jobs are running

[Fredrik Haikarainen via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=368555

Bug ID: 368555
   Summary: KDevelop crashes when you attempt to "Kill All Jobs"
when no jobs are running
   Product: kdevelop
   Version: 5.0.0
  Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
  Keywords: drkonqi
  Severity: crash
  Priority: NOR
 Component: general
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: fredrik.haikarai...@gmail.com

Application: kdevelop (5.0.0)

Qt Version: 5.7.0
Frameworks Version: 5.25.0
Operating System: Linux 4.7.2-1-ARCH x86_64
Distribution (Platform): Archlinux Packages

-- Information about the crash:
- What I was doing when the application crashed:
1. Attempt to install a target
2. It fails with *** Killed process ***
3. No jobs are running, but both "Stop" and "Stop All" buttons are active, and
in the job list the install job is still there.
4. Press Stop All.


Arch Linux x64, using kdesudo for install, works when manually typing in
commandline (kdesudo -- make -j4 install)

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 0x7f8ef7b1e800 (LWP 5459))]

Thread 12 (Thread 0x7f8ea89c5700 (LWP 5559)):
#0  0x7f8eee41f10f in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x7f8ef5016c2b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/libQt5Core.so.5
#2  0x7f8ee9b401c0 in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () from /usr/lib/libKF5ThreadWeaver.so.5
#3  0x7f8ee9b44978 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5
#4  0x7f8ee9b3f263 in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/libKF5ThreadWeaver.so.5
#5  0x7f8ee9b449d2 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5
#6  0x7f8ee9b3f263 in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/libKF5ThreadWeaver.so.5
#7  0x7f8ee9b421f9 in ThreadWeaver::Thread::run() () from
/usr/lib/libKF5ThreadWeaver.so.5
#8  0x7f8ef5015d78 in ?? () from /usr/lib/libQt5Core.so.5
#9  0x7f8eee419454 in start_thread () from /usr/lib/libpthread.so.0
#10 0x7f8ef492b7df in clone () from /usr/lib/libc.so.6

Thread 11 (Thread 0x7f8ea91c6700 (LWP 5558)):
#0  0x7f8eee41f10f in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x7f8ef5016c2b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/libQt5Core.so.5
#2  0x7f8ee9b401c0 in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () from /usr/lib/libKF5ThreadWeaver.so.5
#3  0x7f8ee9b44978 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5
#4  0x7f8ee9b3f263 in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/libKF5ThreadWeaver.so.5
#5  0x7f8ee9b449d2 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5
#6  0x7f8ee9b3f263 in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/libKF5ThreadWeaver.so.5
#7  0x7f8ee9b421f9 in ThreadWeaver::Thread::run() () from
/usr/lib/libKF5ThreadWeaver.so.5
#8  0x7f8ef5015d78 in ?? () from /usr/lib/libQt5Core.so.5
#9  0x7f8eee419454 in start_thread () from /usr/lib/libpthread.so.0
#10 0x7f8ef492b7df in clone () from /usr/lib/libc.so.6

Thread 10 (Thread 0x7f8ea99c7700 (LWP 5557)):
#0  0x7f8eee41f10f in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x7f8ef5016c2b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/libQt5Core.so.5
#2  0x7f8ee9b401c0 in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () from /usr/lib/libKF5ThreadWeaver.so.5
#3  0x7f8ee9b44978 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5
#4  0x7f8ee9b3f263 in
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from
/usr/lib/libKF5ThreadWeaver.so.5
#5  0x7f8ee9b421f9 in ThreadWeaver::Thread::run() () from
/usr/lib/libKF5ThreadWeaver.so.5
#6  0x7f8ef5015d78 in ?? () from /usr/lib/libQt5Core.so.5
#7  0x7f8eee419454 in start_thread () from /usr/lib/libpthread.so.0
#8  0x7f8ef492b7df in clone () from /usr/lib/libc.so.6

Thread 9 (Thread 0x7f8eaa1c8700 (LWP 5556)):
#0  0x7f8eee41f10f in pthread_cond_wait@@GLIBC_2.3.2 () from
/usr/lib/libpthread.so.0
#1  0x7f8ef5016c2b in QWaitCondition::wait(QMutex*, unsigned long) () from
/usr/lib/libQt5Core.so.5
#2  0x7f8ee9b401c0 in
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
bool, bool, bool) () from /usr/lib/libKF5ThreadWeaver.so.5
#3  0x7f8ee9b44978 in ?? () from /usr/lib/libKF5ThreadWeaver.so.5
#4  0x7f8ee9b3f263 in
ThreadWeaver::Weaver::applyForWork(Thread

[kdevelop] [Bug 359067] Auto-completion of method definitions does not follow declaration format or symbols, and breaks convention, and may also break compilation on some systems.

[Fredrik Haikarainen via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359067

--- Comment #2 from Fredrik Haikarainen  ---
I suspect the __cxx11 thing is highly related to GCC, since its specific to
their stdlib, it would make sense that anything that uses clang instead isnt
affected. A proper solution would probably be  to somehow detect the __cxx11
namespace in the renaming utility, and  remove any instance of it that werent
there before.

Regarding the const placement, I dont have time to open another report atm, but
please do so for me if you have time over.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 359067] New: Auto-completion of method definitions does not follow declaration format or symbols, and breaks convention, and may also break compilation on some systems.

[Fredrik Haikarainen via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359067

Bug ID: 359067
   Summary: Auto-completion of method definitions does not follow
declaration format or symbols, and breaks convention,
and may also break compilation on some systems.
   Product: kdevelop
   Version: 4.7.1
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: major
  Priority: NOR
 Component: Language Support: CPP
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: fredrik.haikarai...@gmail.com

When you auto-complete method definitions in a source-file, the resulting code
does not follow the format or symbol-naming of the declaration.

Example:

class someClass
{
std::string const & getFoo();
}

using GCC 5.2.1 with -std=c++11 auto-completes to

const std::__cxx11::string& someClass::getFoo()
{

}

Problem 1: Different format. The const keyword is now leftsided, and  the &
operator is "merged" to the return-type instead of being separated by a space.
This breaks convention of the existing codebase.

Problem 2: Different symbols. std::string auto-completes to
std::__cxx11::string, which I believe is compiler/libc++-specific (someone
please confirm), and will not compile on all systems supporting the C++11
standard.

Reproducible: Always

Steps to Reproduce:
1. Declare a function/method in a headerfile
2. Include said headerfile in a sourcefile and press ctrl+space to autocomplete
the declaration to a definition

Actual Results:  
The autocompleted definition is different that the declaration

Expected Results:  
The autocompleted definition follows the exact signature of the declaration,
both in terms of conventions/formatting as well as which symbols are used.

-- 
You are receiving this mail because:
You are watching all bug changes.

[kdevelop] [Bug 359062] New: Renaming class changes filename but not #include directives

[Fredrik Haikarainen via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=359062

Bug ID: 359062
   Summary: Renaming class changes filename but not #include
directives
   Product: kdevelop
   Version: 4.7.1
  Platform: Ubuntu Packages
OS: Linux
Status: UNCONFIRMED
  Severity: normal
  Priority: NOR
 Component: Language Support: CPP
  Assignee: kdevelop-bugs-n...@kde.org
  Reporter: fredrik.haikarai...@gmail.com

I think the summary is pretty self-descriptive; when you rename a class (using
right-click > rename "Foo"), it renames the filename of the file as well to
reflect the changes (as expected and a nice feature), however it does not
change any #include directives pointing to the file, leading to lots of manual
labour.



Reproducible: Always

Steps to Reproduce:
1. Declare a class named Foo in a file called Foo.hpp
2. Create a file that #include's Foo.hpp (Foo.cpp for example)
3. Rename the class Foo to "Bar" using the renaming tool

Actual Results:  
Any declarations, definitions and usages of class Foo are changed. The file
Foo.hpp is also changed. However any #include directives pointing to Foo.hpp
are not changed, making them obsolete and breaks compilation.

Expected Results:  
Any declarations, definitions and usages of class Foo are changed. The file
Foo.hpp is also changed, along with any #include directive pointing to said
file.

Using official Ubuntu 15.10 packages, which provides version 4.7.1 using KDE
Development Platform  4.14.13

-- 
You are receiving this mail because:
You are watching all bug changes.