first try of KDevelop 5.0.4

Hi,

Post by Django
Ok, nothing new on that item - but I found out, that my app, developed with
KDevelop 4.8 crashes with 5.0.4 as well as with beta version.

I didn't understand that. You mean, you wrote an application and it
crashes when you launch it from KDevelop 5.0.4 and it doesn't when you
do from 4.8?
That's very strange -- KDevelop does nothing except just launching the
process. I don't think this issue is related to KDevelop.

Post by Django
I'm running debian stable, so 4.8 is the version supported by debian and 5.0.4
downloaded as AppImage.
Starting the beta-version from commandline rises this message when crashing

What do you mean by beta-version? 5.0.80?

Post by Django
I'm using -std=c++14 and trying cppcheck from beta fails, as it does not
understand c++14 features.

Hmm, wait, I thought you cannot launch the beta version? :/
Sorry, I'm confused.

Post by Django
P.S. I don't like the new grafical scrollbars with text-preview. Is there an
option to change scrollbars to desktop standard?
P.P.S. I miss the symbol column, where in 4.8 it is possible to enable/disable
breakpoints with a single mouseclick. Is this customizable?

Both can be changed in the Configure Editor dialog, under Appearance ->
Borders.

Greetings,
Sven

Django

2017-03-19 11:48:28 UTC

Hi,

Post by Sven Brauch

Post by Django
Ok, nothing new on that item - but I found out, that my app, developed
with KDevelop 4.8 crashes with 5.0.4 as well as with beta version.

I didn't understand that. You mean, you wrote an application and it
crashes when you launch it from KDevelop 5.0.4 and it doesn't when you
do from 4.8?

Exactly.

Post by Sven Brauch
That's very strange -- KDevelop does nothing except just launching the
process. I don't think this issue is related to KDevelop.

Well, it is an issue of KDevelop. Could it be, that the memory or environment
for the subprocess is different? I don't have any idea of kdevelop, but there's
a difference between the versions of KDevelop.

Post by Sven Brauch
What do you mean by beta-version? 5.0.80?

Yes.

Post by Sven Brauch

Post by Django
I'm using -std=c++14 and trying cppcheck from beta fails, as it does not
understand c++14 features.

Hmm, wait, I thought you cannot launch the beta version? :/
Sorry, I'm confused.

No - I can start 5.0.4 and 5.0.80 - no problem at start of kdevelop. The
problem is, that both start my app differnt to 4.7 (sorry, it's 4.7 not 4.8 as
mentioned earlier)

Post by Sven Brauch
Both can be changed in the Configure Editor dialog, under Appearance ->
Borders.

Found it. Thanks!

cheers Reinhard

Sven Brauch

2017-03-19 11:48:54 UTC

Hi,

Post by Sven Brauch
I didn't understand that. You mean, you wrote an application and it
crashes when you launch it from KDevelop 5.0.4 and it doesn't when you
do from 4.8?

Exactly.

Ok -- probably related to the AppImage, that has a bit of strange stuff
for the subprocesses going on. Is your application open-source? Then I
can try to launch it and see if it does anything strange.

Greetings,
Sven

Milian Wolff

2017-03-19 13:55:57 UTC

Post by Sven Brauch
Hi,

Post by Sven Brauch
I didn't understand that. You mean, you wrote an application and it
crashes when you launch it from KDevelop 5.0.4 and it doesn't when you
do from 4.8?

Exactly.

See also this thread in qt-development:

http://lists.qt-project.org/pipermail/development/2017-March/028934.html

It may or may not be related.

Django, can you show us the output/backtrace of the crash in your application
when you run it from KDevelop? Do you also see it with other applications, or
only this one you developed yourself?

Thanks

--
Milian Wolff
***@milianw.de
http://milianw.de

Django

2017-03-19 14:07:34 UTC

Hi,

Post by Sven Brauch
Ok -- probably related to the AppImage, that has a bit of strange stuff
for the subprocesses going on. Is your application open-source?

No - its not published

Post by Milian Wolff
Django, can you show us the output/backtrace of the crash in your
application when you run it from KDevelop?

How can I get such a backtrace?

Post by Milian Wolff
Do you also see it with other applications, or only this one you developed
yourself?

I did not spend much time in investigation and of cause, I did not test
anything else. As the new releases don't offer things, I am missing, I'm fine
staying at 4.7

Just wanted to inform you.

If it helps you, I'm willing to do some more testing based on your
recommendations. If not - never mind :)

cheers Reinhard

Milian Wolff

2017-03-27 19:57:43 UTC

Post by Django
Hi,

Post by Sven Brauch
Ok -- probably related to the AppImage, that has a bit of strange stuff
for the subprocesses going on. Is your application open-source?

No - its not published

Post by Milian Wolff
Django, can you show us the output/backtrace of the crash in your
application when you run it from KDevelop?

How can I get such a backtrace?

I suggest something like this:

gdb kdevelop
(gdb) run -s <your session>
# wait until everything has finished initialization
# i.e. just before you are about to run your application
# interrupt GDB by pressing Ctrl + C in the CLI, then type:
(gdb) set follow-fork-mode child
(gdb) continue
# now launch your process via kdevelop

It should crash again and you should have GDB notice that. You can then get a
backtrace via

(gdb) thread apply all bt

Post by Milian Wolff
Do you also see it with other applications, or only this one you developed
yourself?

I did not spend much time in investigation and of cause, I did not test
anything else. As the new releases don't offer things, I am missing, I'm
fine staying at 4.7
Just wanted to inform you.
If it helps you, I'm willing to do some more testing based on your
recommendations. If not - never mind :)

Please do look into this - it is potentially a grave issue somwhere. So do
look at the GDB steps above, and do test some other applications to see if
they are affected too.

Cheers

--
Milian Wolff
***@milianw.de
http://milianw.de

René J.V. Bertin

2017-03-27 20:13:13 UTC

Post by Milian Wolff
gdb kdevelop
(gdb) run -s <your session>
# wait until everything has finished initialization
# i.e. just before you are about to run your application

This should work but depending on how large your session is you may win a lot of time, possibly even avoid deadlocks by attaching to the kdevelop session once it's fully started, has done its parsing run etc.:

%> kdevelop -s $sessionID & (or kdevelop --ps &)

Note the pid printed by the shell. Once KDevelop is idle, attach:

%> gdb --pid=$pid

Post by Milian Wolff
(gdb) set follow-fork-mode child
(gdb) continue
# now launch your process via kdevelop

Milian Wolff

2017-03-27 20:33:17 UTC

Post by Milian Wolff
gdb kdevelop
(gdb) run -s <your session>
# wait until everything has finished initialization
# i.e. just before you are about to run your application

This should work but depending on how large your session is you may win a
lot of time, possibly even avoid deadlocks by attaching to the kdevelop

What kind of deadlocks are you talking about? This would also indicate issues
we are unaware of that need to be fixed.

Post by Milian Wolff
(gdb) set follow-fork-mode child
(gdb) continue
# now launch your process via kdevelop

--
Milian Wolff
***@milianw.de
http://milianw.de

René J.V. Bertin

2017-03-27 21:30:03 UTC

Post by Milian Wolff
What kind of deadlocks are you talking about? This would also indicate issues
we are unaware of that need to be fixed.

I have no idea, I've never been able to figure them out. When I start KDevelop under a debugger it happens that sessions never completely open but remain stuck at some point where there are enough threads doing their thing that it's impossible for me to follow what's going on. I've simply learned to use another approach; when I debug KDevelop it's to figure out something else, not to sit around waiting to be able to get to work.

I think it's just an IPC timing issue caused by the instrument (the debugger) interfering enough with the measured process to cause issues.
This is probably on Mac and thus using lldb, my Linux rig is sufficiently less powerful that I probably never even tried to start KDevelop through a debugger.

R.

René J.V. Bertin

2017-03-28 08:23:58 UTC

Post by Milian Wolff
What kind of deadlocks are you talking about? This would also indicate issues
we are unaware of that need to be fixed.

FWIW, I don't build KDE and Qt code for debugging but in release mode, using `-O3 -g` (and link-time optimisation for the clang parser plugin on Linux).
If you can start KDevelop under a debugger, load any size session and end up debugging whatever you wanted to debug within a reasonable amount of time then there is probably no evident issue in KDevelop at all.

And also: there are certain known issues with QProcess in borderline conditions. It's known for instance that QProcess::start() can fail in OOM conditions (= fork() fails), and I have seen issues (including crashes) when helper processes fail to start within the allocated timeout because the system is too busy.
Then there is an issue with using "too many" or a "too large" Qt help collection(s) on Mac which can lead to thread creation failures. Running under a debugger probably shouldn't have any effect on that but I wouldn't be shocked if it did.

R.

Django

2017-03-29 02:57:31 UTC

Post by Django
How can I get such a backtrace?

Thanks for the hints! I'll try that.

I don't know much tools to check an application, so valgrind is the tool of my
choice.