Basic questions to debugging

[ChrisW67]

1. Am I right with my assumption, that I installed Qt and Qwt in release mode?

Qt SDK: no, you get both sets of libraries. Qwt: yes, you went out of your way to build release.

2. Does this mean, that I cannot build debug versions of my application?

No. The compiler in the SDK can build either. You will need to make a debug version of Qwt if you need to debug/profile that code. Your program can be built for debugging either way.

3. I have got the debug button, so do I have a debugger which was provided with Qt-SDK (like gdb or so)?

Yes, gdb. It also included Qt Creator so you did not have to build your own.

4. Why does the program not stop at breakpoints?

Your program (not Qt or Qwt) is built in release mode or the code is never reached.

5. Why does is say "process couldn't be started" when I choose debug instead of release?

The path to the executable may have changed (shadow builds into different directory). Check your Build and Run Settings in Qt Creator. Given this, I guess the answer to 4. is "it's built in release mode."

6. What must my .pro file look like in order to debug or build a debug version? Do I have to add something like config += debug?

You could do that:

CONFIG += debug

CONFIG += debug

To copy to clipboard, switch view to plain text mode 

or you can tell Qt Creator to create a debug version and it will add the relevant option to the qmake command on your behalf:

qmake CONFIG+=debug project.pro

qmake CONFIG+=debug project.pro

To copy to clipboard, switch view to plain text mode 

My PRO files generally contain neither release nor debug and allow the qmake invokation to set.

If I am on the wrong track, where do I have to start to get to my goal (find the bottlenecks)?

You need a better grasp of your tools before you can go much further. Valgrind is Linux only. You could have a read here (or perhaps a MingW compatible gprof?).

You should also take a long look at the code that handles the frequent events. Look for where you are doing things every time that need only be done once or more than the necessary minimum to handle the event.

[emigrand]

You will need to make a debug version of Qwt if you need to debug/profile that code.

OK, first of all: This helped me understand a lot more than I did before, thanks! I can work with the debugger now, it stops at breakpoints, I can monitor variables, etc. - that's great. The error message "cannot find -lqwtd" I received when I tried to debug my plotting program was due to having built Qwt in release mode - this wasn't obvious to me at all . In the meantime, I found the bottleneck in my code (which I reduced to non-Qwt elements for testing): verysleepy says that a lot of time (82 %) is spent in the function cbVIn(), which is from the AD-converter library. Timecostly is as well replotting, I think.

Anyway, in order to be able to debug my code which contains Qwt elements, what do I have to do? As you said: make a debug version of Qwt - right? How do I do that? According to my protocoll mentioned above:

• Download the newest version of qwt and unzip to C:\qwt-6.0.1
• Add the line "CONFIG += debug" to qwt.pro (after "CONFIG += ordered")
• Open command shell, cd to Qwt-folder and type qmake qwt.pro -spec win32-g++ -r CONFIG+=debug
• type mingw32-make
• type mingw32-make install

Do I have to remove the release version beforehand? What else do I have to keep in mind? Do I run the risk of destroying my previous Qwt build and spending weeks with reestablishing the system as it was?

Thank you for your patience...

[ChrisW67]

To debug your code using Qwt components does not require a debug Qwt: to debug Qwt code does.

Your build of the debug Qwt looks OK (the second step is unneeded because the third step supplied the debug option anyway). You should not need to remove the release version, which you can link using "-lqwt" or similar, only the end library should differ and it will generally have a different name. (BTW: you can install the release and debug version into entirely different locations if you wish).

In your code's PRO file you should link to the debug version of the Qwt library: i.e. "-lqwtd". This can be automated using qmake using scopes in your PRO file:

CONFIG(release, debug|release) {
  message(Release build!)
  LIBS+=-Lc:/qwt-6.0.1/bin -lqwt
...
}
CONFIG(debug, debug|release) {
  message(Debug build!)
  LIBS+=-Lc:/qwt-6.0.1/bin -lqwtd
...
}

CONFIG(release, debug|release) {
  message(Release build!)
  LIBS+=-Lc:/qwt-6.0.1/bin -lqwt
...
}
CONFIG(debug, debug|release) {
  message(Debug build!)
  LIBS+=-Lc:/qwt-6.0.1/bin -lqwtd
...
}

To copy to clipboard, switch view to plain text mode 

Timecostly is as well replotting, I think.

Since no human is going to keep up with 1000+ samples/second anyway, you should consider capturing the data every cycle but only redrawing the plot every 500 samples or the like.

[emigrand]

Since no human is going to keep up with 1000+ samples/second anyway, you should consider capturing the data every cycle but only redrawing the plot every 500 samples or the like.

I implemented something similar already, so replotting efforts are minimized, problem vanished!

To debug your code using Qwt components does not require a debug Qwt:

This is what I want to do. Writing my own program using Qwt classes. Then I want to debug the whole thing.

to debug Qwt code does.

Where is the difference? Or would this mean debugging the Qwt libraries and stuff?? I wouldn't dare, should I? So according to my goal outlined above, I still assume that I don't need to make a debug vesion of Qwt in order to be able to debug code that uses Qwt classes. But: If I do so, I get the error messages already mentioned:

:: error: cannot find -lqwtd
:: error: collect2: ld returned 1 exit status

Your build of the debug Qwt looks OK

Which build? I just asked if this is the way I would have to build it. But if I don't need to...(see above). But maybe I got this whole thing wrong again and I am supposed to build the debug version, otherwise I will not get rid of the errors??

I really would like to add these lines to my .pro file, because it looks clear and obvious:

CONFIG(release, debug|release) {
  message(Release build!)
  LIBS+=-Lc:/qwt-6.0.1/bin -lqwt
...
}
CONFIG(debug, debug|release) {
  message(Debug build!)
  LIBS+=-Lc:/qwt-6.0.1/bin -lqwtd
...
}

CONFIG(release, debug|release) {
  message(Release build!)
  LIBS+=-Lc:/qwt-6.0.1/bin -lqwt
...
}
CONFIG(debug, debug|release) {
  message(Debug build!)
  LIBS+=-Lc:/qwt-6.0.1/bin -lqwtd
...
}

To copy to clipboard, switch view to plain text mode 

But I don't have a /bin-folder!!! Should this observation tell me something? Does it tell you something about my installation or mental condition?

I hope for the first...
Thank you Chris for your patience so far...

[ChrisW67]

If you need to single step through your code code then your code must be built with debug symbols. As you step through your code and it enters Qwt functions in the library you will either:

• See a low level disassembly of the release mode Qwt library routine, or
• A high level source code view of the debug mode Qwt library routine. (The source is embedded in the library to enable this.)

It seems unlikely that you want/need to debug the Qwt code. You can Step Over the Qwt calls to avoid the disassembly.

I am not intimately familiar with Windows Qwt builds. I assumed that the debug mode Qwt library would follow the same convention as the Qt libraries; appending a 'd' so that release and debug can exist side-by-side. If the debug library gets the same name, i.e. qwt.dll, then you are better off building release mode and installing into Path A, and debug mode installed into Path B and adjust INCLUDEPATH and LIBS accordingly.

I also assumed a directory structure. You will have to adjust paths to suit what has actually happened on your machine.