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.resize(8); 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; timer.setSingleShot(true); QEventLoop loop; connect(&timer, SIGNAL(timeout()), &loop, SLOT(quit())); timer.start(100); loop.exec(); return success; //<- here the debugger stops! } bool writeCanMessage(quint32 identifier, QByteArray payload) { QCanBusFrame frame; frame.setFrameId(identifier); frame.setPayload(payload); 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! :-)
-
@robro said in Stack Overflow, why?:
timer.setSingleShot(true);
QEventLoop loop;
connect(&timer, SIGNAL(timeout()), &loop, SLOT(quit()));
timer.start(100);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.
Edit:
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. -
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?
-