Breakpoints never reached in main.cpp, when they really should be

[Bernd Wechner]

Myriam Schweingruber wrote:
 > Disclaimer: I am not a coder, I just understand some code when I see 
it, but can't
 > write well enough to be useful as a dev.

No worries, your patience with me is appreciated all the same!

 > I don't really see the reason to set breakpoints in main.cpp, as this 
only calls the
 >  other modules needed to execute Amarok,

Just a proof of concept. When testing a new IDE, a new debugger etc, 
fairly standard practice to fire up the app and trest a break, and play 
around in the IDE to inspect vars, stack and single step and so on. Baby 
steps. The only place you KNOW the app is going to is main(), so you 
break on line 1 there to get rolling.

|> |so if that execution doesn't happen, of course your breakpoints will 
not be reached.
 > A lot of services are started when Amarok starts, as well as the 
database initialisation,
 > the GUI drawing, the existing playlist reading, etc, so there are a 
lot of things that will
 > happen before any of your breakpoint is reached.

Understanding all that is useful. Is there an Amarok bootstrap guide? 
Where is all that happening? In "KUniqueApplication::start( startFlag )"?

Should I do some reading of KDE?

 >Maybe have a look at the architecture of Amarok, there is a nice map 
in the source tree Ralf
 > made a few years back, that might give you some more information 
about the structure of
 > Amarok.

Do you mean this stuff: ~/kde/src/amarok/HACKING/architecture?

If so, anything and everything is always appreciated, but lacks a 
startup walkthrough.

 > There are over 500'000 lines of code in Amarok, it is quite a complex 
beast, and I doubt main.cpp
 > will help you much as a starter. Looking at a specific element of 
Amarok (GUI, services, playlist,
 > browser, database, etc) might be more useful.

Agreed, but I can't break anywhere else that be the problem. I just 
retired a few ways and here is the result:

1) I can build and run in QtCreator - all fine.

2) I can debug and two amarok processes and a gdb process are visible 
but I never see a UI nor System tray icon (but if I run, not debug both 
appear reliably).

3) If I set a breakpoint at start of main() and debug, then QtCreator 
throws me into the editor at that line when it breaks and I can examine 
variables without trouble. If I continue, same as 2). I see one gdb and 
two amarok processes running (ps) when interrupted.

4) If I run "gdb amarok" on the binary (in ~/kde/build/amarok/src) and 
"run" the UI and System Tray icon fire up fine.

5)If I set a breakpoint at line 127 in MainWindow.cpp (the constructor 
for MainWindow) and debug in QtCreator same as 2) above.

6) If I try similar in gdb I get:

    (gdb) break MainWindow::MainWindow
    Function "MainWindow::MainWindow" not defined.
    Make breakpoint pending on future shared library load? (y or [n])

which hints at an issue. If I say yes and run, then the UI and Sys Tray 
icon fire up I can interact with Amarok but the breakpoint never 
triggers. And that may well relate to QtCreators issue, but Qt Creator 
won't even fire up the UI alas in debug mode. The *Application output 
*in  QtCreator shows only:

Debugging starts

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


If you can break on any line in the UI code, nominate one (file and line 
number) and I'll try and do same.

Thanks enormously for the support Myriam. Anyone with a working 
QtCreator who can break anywhere in Amarok can help me here by holding 
my hand in a sense through the experience. I'm getting no joy yet.

My theory is  simple:

a) Amarok is big and developed
b) Therefore people have been developing it
c) I presume them to use an IDE with debugging to do so
d) These people seem to use QtCreator dominantly
e) It must work, either out of the box or with special Amarok tweaks 
therefore
f) I need to find someone who can do it, and has the time and patience 
to walk through it with me to help find why I can't.

This is a roadblock for me alas.

Regards,

Bernd.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20160324/c7911efa/attachment.html>