OK, am stepping through amarok code in QtCreator and find the most bizarre behaviour as follows.

Using the latest git snapshot from git://anongit.kde.org/amarok.git

in main.cpp I can set a breakpoint at line 300 which reads:

Code: Select all

    if( !KUniqueApplication::start( startFlag ) )

I can set breakpoints anywhere after this in main.cpp and they are never reached. If I single step over line 300, it amarok UI just fires up and enters its wait loop for events.

This strikes me as particularly odd as it is not until line 329:

Code: Select all

    return app.exec();

that it looks like the app is fired up proper and this looks suspsciously like a debugging issue with QtCreator.

Another thought is that perhaps the binary is compiled with some optimisation or some other confounding issue that mucks up the tie between the built binary and the source code. Am guessing wildly and keen to learn.

Regards,

Bernd.

Turns out same is true almost anywhere else! I am setting breakpoints for example in the ExtendedAboutDialog constructor and it never triggers. I can be debugging Amarok, and display the About dialog box but my breakpoint never breaks.

Something fishy going on.

I wonder if amarok is forking and the child process is not attached to gdb?

Do you build with debug symbols?

scummos wrote:Do you build with debug symbols?

I believe so. How can I be sure?

I use the cmake command line option -DCMAKE_BUILD_TYPE=debugfull

and can't find anywhere else to set it.

Plus of note is that I can debug it up to line 300 in main.cpp, so the amarok binary is clearly built with debug symbols.

My thought is that amarok forks and gdb needs to follow children. But if I set the Debug all children option on the GDB Extended tab of the Debugger Options (Tools > Options), alas I see no improvement.

Are you able to debug amarok with breakpoints in QtCreator?

Try running it in gdb directly, then type "break main.cpp:300". gdb will shout at you if it could not find the target location for that breakpoint.

Been on that last night. gdb breaks fine and unlike QtCreator can single step past it. But ends up inside a Qt system file:

Code: Select all

(gdb) step
QFlags<KUniqueApplication::StartFlag>::QFlags (this=0x7fffffffdd60, f=(unknown: 0)) at /usr/include/qt4/QtCore/qglobal.h:2322
2322       Q_DECL_CONSTEXPR inline QFlags(Enum f) : i(f) {}


show inferiors shows one thread at his point.

One more step after this and it seems to hang spewing forth:

Code: Select all

(gdb) step
[New process 28134]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Reading symbols from /home/bernd/kde/build/amarok/lib/libamarokcore.so.1...done.
Reading symbols from /home/bernd/kde/build/amarok/lib/libamaroklib.so.1...done.
Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so...done.
Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libpthread-2.19.so...done.
Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libm-2.19.so...done.
Reading symbols from /home/bernd/kde/build/amarok/lib/libamarokshared.so.1...done.
Reading symbols from /home/bernd/kde/build/amarok/lib/libamarokpud.so.1...done.
Reading symbols from /home/bernd/kde/build/amarok/lib/libamarokocsclient.so.4...done.
Reading symbols from /home/bernd/kde/build/amarok/lib/libamarok-transcoding.so.1...done.
Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libdl-2.19.so...done.
Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/librt-2.19.so...done.
Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.19.so...done.
Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libnsl-2.19.so...done.
Reading symbols from /usr/lib/debug/lib/x86_64-linux-gnu/libresolv-2.19.so...done.
Reading symbols from /usr/lib/debug/usr/lib/x86_64-linux-gnu/gconv/UTF-16.so...done.

but it sit there till I lose patience, press CTRL+C and the show inferiors shows two threads.

No surprise given the message. I started the session with set detach-on-fork off following this nice guide:

http://moss.cs.iit.edu/cs351/gdb-inferiors.html

Step learning curve. Been decades since I used a CLI debugger (in the days of disassembling and hacking game binaries to get around protection .

Sorry, I'm not entirely sure what your problem is right now. What gdb CLI does there seems fine to me. Loading the debug symbols might, depending on your system and the program you debug, take quite a while, so be patient.

Why QtCreator does not hit the breakpoint I do not know, maybe you should report a bug with them...

scummos wrote:Sorry, I'm not entirely sure what your problem is right now. What gdb CLI does there seems fine to me. Loading the debug symbols might, depending on your system and the program you debug, take quite a while, so be patient.

Why QtCreator does not hit the breakpoint I do not know, maybe you should report a bug with them...

Thanks, will try patience . Am cutting my teeth on it. How patient is patient though, there's 1 minute patience, 10 minute, 100 minute, 1000 minute, when do you give up and break with CTRL+C? I'm happy to stretch my patience but curious to what target. As a patient test I can start it before hitting bed and see what it's like in morning .

But part of my problem I guess is:

1) Understanding what Amarok is doing. Better said I suspect it's a standard KDE QT application startup and that "KUniqueApplication::start( startFlag )" forks. Questions in my mind are why? DO I care? Should it matter? Is this not how all QT apps start? Or is this a KDE specific issue?

2) Believing that this is normal in QtCreator - it's a QT creator and used by Amarok developers so I assume it must break sensibly beyong line 300 so I am presuming there is something to learn here, that some config or something I can or should do, is missing. It is hard to imagine this is a bug in QtCreator, as I'm asking it to do something that I would have though ubiquitous and needed among its users. But perhaps that premise is faulty?

Thanks, will try patience . Am cutting my teeth on it. How patient is patient though, there's 1 minute patience, 10 minute, 100 minute, 1000 minute, when do you give up and break with CTRL+C?

gdb will continue printing what library it is loading symbols from. As long as it keeps printing new libraries and doesn't take more than, say, 30 seconds for one, just let it work, it will finish. Shouldn't take more than at most 3 minutes overall even on a very slow system though. Here it's usually done in 3 seconds at most.

1) Understanding what Amarok is doing. Better said I suspect it's a standard KDE QT application startup and that "KUniqueApplication::start( startFlag )" forks. Questions in my mind are why? DO I care? Should it matter? Is this not how all QT apps start? Or is this a KDE specific issue?

Here I'm not really with you any more, because I don't know what issue you want to debug. KUniqueApplication is a KDE class, it is not used by pure Qt apps. Can you explain what you're trying to do?

Sorry for not being able to help with Qt Creator, I'm neither a user nor a developer of that ... maybe somebody else?

as QtCreator is a QT product maybe you should try their forums https://forum.qt.io, probably https://forum.qt.io/category/13/tools

scummos wrote:Here I'm not really with you any more, because I don't know what issue you want to debug. KUniqueApplication is a KDE class, it is not used by pure Qt apps. Can you explain what you're trying to do?

Oh, I'm not trying to debug anything yet. I'm trying to set myself up with an IDE that can debug Amarok! That is all. Proof of concept.

QtCreator seems the IDE of choice or KDevelop but I have had less luck with Kdevelop so focussed so far on QtCreator because I found two people using it on IRC!

All I need is a modus operandi. A way to run Amarok in debug mode in an IDE, to set breakpoints wherever desired, and then inspect the stack the variables, single step, continue, break etc, standard debugging needs. I presume this is the norm among Amarok developers (it's been the norm for me and everyone I've worked with for decades with Visual Studio or Eclipse say).

All I've done is run Amarok in QtCreator debug mode and am looking to debug it. But I can't set a breakpoint anywhere past line 300 of main.cpp and have QtCreator break. I presume it's a use/config issue as I presume happy creators developers across the board are working with Amarok in QtCreator is all.

Reason I'm looking at gdb in the CLI is primarily because QtCreator reports:

Debugging starts
&"warning: GDB: Failed to set controlling terminal: Inappropriate ioctl for device\n"

But on-line research suggests that's meaningless and not a concern (just that gdb isn't run with terminal)

So I'm just playing around to further my skills and understanding I guess, no really meaning to debug anything right now, so much as know how when I do want to.

As gdb is the backend that QtCreator uses, understanding it empower me.

Anyhow it turns out I just tried:

Code: Select all

$ gdb amarok
...
(gdb) break 300
(gdb) run
Starting program: /home/bernd/.local/share/Trash/files/src/amarok
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, main (argc=1, argv=0x7fffffffde98) at /home/bernd/kde/src/amarok/src/main.cpp:300
300       if( !KUniqueApplication::start( startFlag ) ) {
(gdb) set follow-fork-mode child
(gdb) step
QFlags<KUniqueApplication::StartFlag>::QFlags (this=0x7fffffffdd40, f=(unknown: 0)) at /usr/include/qt4/QtCore/qglobal.h:2322
2322       Q_DECL_CONSTEXPR inline QFlags(Enum f) : i(f) {}
(gdb) Quit
(gdb)

Or in summary, when following the child I can step and it breaks. Alas if I repeat this now with "set follow-fork-mode parent" it also single steps fine. Something has changed and I don't know what.

At this point in gdb I can even successfully do:

Code: Select all

(gdb) break MainWindow::MainWindow
Breakpoint 2 at 0x7ffff67d8fb0 (2 locations)
(gdb) continue

And gdb continues and breaks at the start of the MainWindow constructor. Awesome.

Alas if I do

But the goal is just to have a decent IDE with visual debugger working.

Code: Select all

(gdb) break ExtendedAboutDialog::ExtendedAboutDialog
Breakpoint 2 at 0x7ffff67dda10 (2 locations)
(gdb) continue


I never hit the breakpoint. The UI fires up. I can display the About Amarok dialog box and no fire.

If I CTRL+C I can see:

Code: Select all

(gdb) info inferiors
  Num  Description       Executable       
* 3    <null>            /home/bernd/.local/share/Trash/files/src/amarok
  2    <null>            /home/bernd/.local/share/Trash/files/src/amarok
  1    <null>            /home/bernd/.local/share/Trash/files/src/amarok

and the Dialog box and main window appear as distinct windows in the Cinnamon task bar so I'm think forking is happening again and for some reason gdb today will break at the MainWindow constructor but not the ExtendedAboutDialog constructor.

I'm being a tad weirded out here alas and wish it would all just work I guess. But hey, I potter on.

google01103 wrote:as QtCreator is a QT product maybe you should try their forums https://forum.qt.io, probably https://forum.qt.io/category/13/tools

Not a bad idea, and will consider it. My hope for now is simply to find an IDE I can work on Amarok with. And it's proving a pain.

I'll take a second look at Kdevelop with what I've learned so far. I was stuck on that too.

Am following this:

https://community.kde.org/Amarok/Development/Hacking_On_Amarok_HowTo

and updating it with what I learn.

My thinking is that, if there are developers working on Amarok in QtCreator they have this nailed and these are the folk I'm hoping to tap into and to make sure whatever I learn is documented on that wiki page so newbs can hop on board.

I get the impression development on amarok is a tad stagnant and it certainly doesn't help if getting started is not easy!

The how to I'm following had scant info and I am roadblocks on both IDEs it introduces alas.

Ah yes, that makes sense of course; I think KUniqueApplication might even go through dbus or so, read the source to be sure. You might try adding the follow command into your ~/.gdbinit or so.

It's hard for me to say anything about your issues without having your system in front of me ... one thing you can try is adding a qDebug() statement where you break (then recompile) to make sure the code you want to break in is actually executed. Sometimes unexpected code paths are taken and it is correct that your breakpoint is not hit.

Greetings,
Sven