Important: Please read the Qt Code of Conduct -

Stack Overflow, why?

  • Hello,

    I have a bug causing a stack overflow, but I have absolutely no clue what the problem could be.

    Basically I am sending messages to a CAN interface and if I do it quickly I get a stack overflow.
    If I wait some milliseconds before calling the function again the program runs fine.

    This is the code where the debugger stops:

    bool transmitMessage(int NodeNumber, const int &var1, const int &var2)
         quint32 Id = getID(NodeNumber);
         QByteArray ba;
         ba[0] = (qint8) var1;
         ba[1] = (qint8) (var1>> 8);
         ba[2] = (qint8) (var1>> 16);
         ba[3] = (qint8) (var1>> 24);
         ba[4] = var2;
         ba[5] = (qint8) (var2>> 8);
         ba[6] = (qint8) (var2>> 16);
         ba[7] = (qint8) (var2>> 24);
         bool success = writeCanMessage(cobId,ba);
         QTimer timer;
         QEventLoop loop;
         connect(&timer, SIGNAL(timeout()), &loop, SLOT(quit()));
         return success; //<- here the debugger stops!
    bool writeCanMessage(quint32 identifier, QByteArray payload)
        QCanBusFrame frame;
        return (ptrCanBus->writeFrame(frame)); //pointer to QCanBusDevice

    Error message: Exception in thread 12 at 0x755f13b8, code 0x0c00000fd: stack_overflow, flags=0x0 (first chance).

    What could be the reason or how can I find the error?

    Thank you very much! :-)

  • Lifetime Qt Champion

    @robro said in Stack Overflow, why?:

    QEventLoop loop;
    connect(&timer, SIGNAL(timeout()), &loop, SLOT(quit()));

    Why do you create a local event loop? You are asking for trouble here.

    Btw, which CAN plugin do you use? And which Qt version, on which platform and which compiler?

  • Thanks for the answer.
    Basically I thought the event loop is a good way to make a break.
    If I send the Can messages without a delay they are to quick for the receiving Can-Bus participant.

    I use the PeakCan plugin provided by / with Qt 5.9.1 with MSVC2017 x64 on Win 10.

    The 100 ms are unnecessary long.
    Still I have no clue why there is a stack overflow as I only call the function again after the previous has returned.

  • When dealing with stack overflow it's usually useful to look at at the stack trace, it will be very long but you should notice a repeating pattern that can signal where the problem is

  • Lifetime Qt Champion


    I guess the problem is, that the Peak plugin in background also relies on the event loop, so maybe things sum up very quickly. Would be indeed interesting to see the stacktrace @VRonin mentioned.

    But for solving this: if delaying the transmit is your goal, why not simply send the messages from a timer slot?

  • Thank you very much!

    I have not found out the reason for the overflow.

    If someone is interested in analyzing the problem you find attached a stack log and a backtrace which might be helpful.
    File1 File2

    As a solution I will use the suggested timer slot :-)

Log in to reply