2

While running my Qt5 project, I get warnings such as

QObject::startTimer: Timers cannot be started from another thread

and others.

While many answers cover what in a given code caused these warnings, or how to correct them, I would like to know where in the code was the warning generated, a traceback.

This is because I think it is being caused by my incorrect usage of some Qt functionality that causes warnings internally, such as, in the above case, functionality that uses timers to execute. Knowing the line number would be helpful for debugging, but unfortunately that is not shown, even in debug mode.

Is there a way to do this?

This question seems to be almost identical, but I am not observing anything similar to what is posted in the question there - I don't see any line numbers. I didn't understand how to apply the answer there, if applicable.

Thank you.

Community
  • 1
  • 1
GoodDeeds
  • 7,956
  • 5
  • 34
  • 61
  • The answer is the same though. Basically you use a custom message handler for warnings and put a breakpoint there. – nwp Mar 08 '17 at 16:23
  • 1
    Possible duplicate of [How to redirect qDebug, qWarning, qCritical etc output?](http://stackoverflow.com/questions/4954140/how-to-redirect-qdebug-qwarning-qcritical-etc-output) – nwp Mar 08 '17 at 16:24
  • @nwp Thank you very much for the link. However, it is not working correctly for my warning messages. I have edited my question with the results. – GoodDeeds Mar 08 '17 at 16:30
  • What do you mean it does not work correctly? You need to put the breakpoint on the `case QtWarningMsg:`, but otherwise it should work the same. If you actually managed to get a warning without the handler being called make a [mcve] so it can be debugged in depth. It is supposed to work. – nwp Mar 08 '17 at 16:33
  • @nwp Sorry for the confusion. The handler is called, but `context.file` and `context.function` give `null` , and `context.line` gives `0` (as edited in my question). So it doesn't help yet. – GoodDeeds Mar 08 '17 at 16:34
  • 1
    You should still be able to put a breakpoint there and then go up the call stack to find out which line of your code caused the warning. – nwp Mar 08 '17 at 16:36
  • @nwp Thank you! That worked. – GoodDeeds Mar 08 '17 at 17:05

2 Answers2

1

The best way is setting a breakpoint, as the others mentioned.

On Linux, it is also possible to include the backtrace in the message pattern:

qSetMessagePattern("%{file}:%{line} - %{message}\n%{backtrace depth=10 separator=\"\n\"}");

Have a look at its documentation, especially for the limitations. Example output:

/home/thomas/src/Qt/5.8-desktop/qtbase/src/corelib/kernel/qobject.cpp:1639 - QObject::startTimer: Timers can only be used with threads started with QThread
QObject::startTimer
QTimer::start
?myapp?
__libc_start_main
?myapp?

Because I am not linking with -rdynamic, the main() function is not known in the backtrace and ?myapp? is printed instead.

Thomas McGuire
  • 5,308
  • 26
  • 45
0

nwp, in the comments, pointed out this answer by Nawaz, which works great when I put a break point on the warning message line, here:

case QtWarningMsg:
        fprintf(stderr, "Warning: %s (%s:%u, %s)\n", localMsg.constData(), context.file, context.line, context.function); //break point here
        break;

This gives a proper traceback when running in the debugger mode, as I needed.

Community
  • 1
  • 1
GoodDeeds
  • 7,956
  • 5
  • 34
  • 61