Bug 389100

Summary: Debugged application crashes when hitting Q_ASSERT(false)
Product: [Applications] kdevelop Reporter: Michael Heidelbach <ottwolt>
Component: generalAssignee: kdevelop-bugs-null
Status: RESOLVED WORKSFORME    
Severity: major    
Priority: NOR    
Version First Reported In: 5.2.1   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Michael Heidelbach 2018-01-17 10:32:11 UTC
Running this
```
#include <QDebug>
int main(int argc, char *argv[])
{
    Q_ASSERT(false);
    qDebug() << "I'm still alive";
    return 0;
}
```
in KDevelop results in this:
```
/home/super/devel/qassk/build> /home/super/devel/qassk/build/qassk
ASSERT: "false" in file ../main.cpp, line 4
*** Failure: /home/super/devel/qassk/build/qassk has crashed ***
```

in qtcreator:
```
Debugging starts
&"warning: GDB: Failed to set controlling terminal: Unpassender IOCTL (I/O-Control) f\303\274r das Ger\303\244t\n"
I'm still alive
Debugging has finished
```
Comment 1 Milian Wolff 2018-01-17 12:34:17 UTC
are you maybe using a debug build in KDevelop and a release build in Qt Creator? One way or another, the QtCreator behavior is the unexpected one, you seem to be compiling without assertions there.

The behavior you show for KDevelop is the expected one for a debug session, i.e. with a debug build of your application.
Comment 2 Michael Heidelbach 2018-01-17 13:29:36 UTC
(In reply to Milian Wolff from comment #1)
> are you maybe using a debug build in KDevelop and a release build in Qt
> Creator? 

$ file /usr/bin/kdevelop
/usr/bin/kdevelop: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=a25f68e11f0df7e95e0881b060e3dc9fec6563bb, stripped

1) Before I tried this I had resetted KDev.-settings to defaults + removed everything from the environment.
2) In the meantime I tried using qtcreator with the previously saved enviroment settings  from KDev.
Now look:
```
ASSERT: "docId > 0" in file ... src/frameworks/baloo/src/engine/idfilenamedb.cpp, line 104
Das Programm ist abgestürzt.
The process was ended forcefully.
... build/frameworks/baloo/bin/balooctl crashed.
```
So apparently my setup is borked. I haven't figured out what it is yet. 

> One way or another, the QtCreator behavior is the unexpected one,
> you seem to be compiling without assertions there.
Really? The app is expected to crash? How can I debug an application that doesn't pass Q_ASSERT(false). Is there a global flag or something to disable assertions and still have 'qDebug() << "bla";' work? 
I'm using c++/cmake et. al. only for 2 weeks now => zero..lowest experience.
Comment 3 Michael Heidelbach 2018-01-17 14:13:25 UTC
Follow up:
I shouldn't have stopped reading the manual after this:
"Prints a warning message containing the source code file name and line number if test is false."
because later:
... qFatal ...
That answers most of my questions. In conclusion: WORKSFORME two.
Comment 4 Milian Wolff 2018-01-18 09:46:05 UTC
The way you compiled KDevelop/QtCreator doesn't matter. Only the debuggee application matters - e.g. the trivial code you posted.

Assertions are there to not be hit. If you hit one, fix it. Or remove the assertion if it's wrong.