Unix signals and QCharts cause application blocking

tovax

@JonB
I can only make sure that the driver is working correctly at the time of the freeze, and I don't know what state the socket is in. Can you give me some guidance? The thread pool was tested yesterday, and the sub threads did not output when it was frozen.

JonB

@tovax
Put regular qDebug() statements into unixSignalHandler() & qtSignalHandler(), and also in timerEvent(), say between every line, and see what the last output you get was.

tovax

@JonB said in Unix signals and QCharts cause application blocking:

@tovax
Your timer times out every 100ms, and in the slot you sleep for 100ms. This may not be a good combination. This implies it will be close to permanently sleeping: as soon the sleep terminates the next timer timeout will occur and go back into sleep more or less immediately. BTW, if you expect the timer timeout to only start counting again after the sleep, that's not the way it works. I suggest any sleep needs at least to be for a lesser period than the repeated time outs, e.g. no more than 50 for a timeout of 100?

In the case of driving working, it is indeed a critical value for sleep time to be equal to the timing period. When the sleep time is less than the timing period, the test is no problem. When the sleep time is greater than or equal to the timing period, it can cause the application to freeze forever.

When the driver is not working, the sleep time is independent of the timing cycle, and the application works normally.

JonB

@tovax
The QTimer you are using is not precisely "accurate". If you rely on it being exactly 100ms that is not good.

If I were you I would still want to know where/why the "freeze" occurs.

tovax

@JonB said in Unix signals and QCharts cause application blocking:

@tovax
Put regular qDebug() statements into unixSignalHandler() & qtSignalHandler(), and also in timerEvent(), say between every line, and see what the last output you get was.

void PanelDriver::unixSignalHandler(int)
{
    qDebug() << __FUNCTION__ << 0;
    char a = 1;
    ::write(mSocketFd[0], &a, sizeof(a));
    qDebug() << __FUNCTION__ << 1;
}

void PanelDriver::qtSignalHandler()
{
    qDebug() << __FUNCTION__ << 0;
    mSocketNotifier->setEnabled(false);
    qDebug() << __FUNCTION__ << 1;
    char tmp;
    ::read(mSocketFd[1], &tmp, sizeof(tmp));
    qDebug() << __FUNCTION__ << 2;

    // do Qt stuff
    static int cnt = 0;
    qDebug() << __FUNCTION__ << cnt++;
    emit panelChanged();
    qDebug() << __FUNCTION__ << 3;

    mSocketNotifier->setEnabled(true);
    qDebug() << __FUNCTION__ << 4;
}

debug output:

unixSignalHandler 0
unixSignalHandler 1
unixSignalHandler 0
unixSignalHandler 1
timerEvent QTime("18:43:29.352")
qtSignalHandler 0
qtSignalHandler 1
qtSignalHandler 2
qtSignalHandler 56
qtSignalHandler 3
qtSignalHandler 4
unixSignalHandler 0
unixSignalHandler 1
unixSignalHandler 0
unixSignalHandler 1
unixSignalHandler 0
unixSignalHandler 0
unixSignalHandler 0
unixSignalHandler 0
unixSignalHandler 0

From the debugging output, the possible problem is:

 :: write (mSocketFd [0],&a, sizeof (a));

tovax

@JonB said in Unix signals and QCharts cause application blocking:

@tovax
The QTimer you are using is not precisely "accurate". If you rely on it being exactly 100ms that is not good.

If I were you I would still want to know where/why the "freeze" occurs.

Yes, I particularly want to know why this abnormal freezing occurs.

JonB

@tovax
The fact that you show many unixSignalHandler 0 in a row with no alternating unixSignalHandler 1 in between (like it does to start out with) means that you keep re-entering unixSignalHandler(), writing a byte, and then not even completing the write() because you don't see the 1 output.

I don't know why that is, and why you get so many signals in a row. It seems to me their sample code approach assumes the write() will complete and the Qt handler will read() after each write() before the next one. Which for whatever reason is not happening in your case.

tovax

@JonB said in Unix signals and QCharts cause application blocking:

@tovax
The fact that you show many unixSignalHandler 0 in a row with no alternating unixSignalHandler 1 in between (like it does to start out with) means that you keep re-entering unixSignalHandler(), writing a byte, and then not even completing the write() because you don't see the 1 output.

I don't know why that is, and why you get so many signals in a row. It seems to me their sample code approach assumes the write() will complete and the Qt handler will read() after each write() before the next one. Which for whatever reason is not happening in your case.

Based on your analysis and debugging output, I added a mutex, but the result is the same. I cannot understand it.

void PanelDriver::unixSignalHandler(int)
{
    qDebug() << __FUNCTION__ << 0;

    QMutexLocker locker(&mMutex);

    char a = 1;
    ::write(mSocketFd[0], &a, sizeof(a));
    qDebug() << __FUNCTION__ << 1;
}

debug output:

unixSignalHandler 0
unixSignalHandler 1
unixSignalHandler 0
unixSignalHandler 1
unixSignalHandler 0
unixSignalHandler 1
timerEvent QTime("19:13:56.243")
qtSignalHandler 0
qtSignalHandler 1
qtSignalHandler 2
qtSignalHandler 63
qtSignalHandler 3
qtSignalHandler 4
unixSignalHandler 0
unixSignalHandler 1
unixSignalHandler 0
unixSignalHandler 1
unixSignalHandler 0
unixSignalHandler 1
unixSignalHandler 0
unixSignalHandler 1
unixSignalHandler 0
unixSignalHandler 0
unixSignalHandler 0
unixSignalHandler 0
unixSignalHandler 0

tovax

@JonB said in Unix signals and QCharts cause application blocking:

@tovax
The fact that you show many unixSignalHandler 0 in a row with no alternating unixSignalHandler 1 in between (like it does to start out with) means that you keep re-entering unixSignalHandler(), writing a byte, and then not even completing the write() because you don't see the 1 output.

I don't know why that is, and why you get so many signals in a row. It seems to me their sample code approach assumes the write() will complete and the Qt handler will read() after each write() before the next one. Which for whatever reason is not happening in your case.

Using the enable flag has the same result.

void PanelDriver::unixSignalHandler(int)
{
    qDebug() << __FUNCTION__ << 0;

#if 0
    QMutexLocker locker(&mMutex);
#else
    static bool enable = true;
    if (!enable)
        return;
#endif

    enable = false;
    char a = 1;
    ::write(mSocketFd[0], &a, sizeof(a));
    enable = true;

    qDebug() << __FUNCTION__ << 1;
}

tovax

@JonB said in Unix signals and QCharts cause application blocking:

@tovax
The fact that you show many unixSignalHandler 0 in a row with no alternating unixSignalHandler 1 in between (like it does to start out with) means that you keep re-entering unixSignalHandler(), writing a byte, and then not even completing the write() because you don't see the 1 output.

I don't know why that is, and why you get so many signals in a row. It seems to me their sample code approach assumes the write() will complete and the Qt handler will read() after each write() before the next one. Which for whatever reason is not happening in your case.

It is also a failure, and continuous output "unixSignalHandler 0" after freezing.

void PanelDriver::unixSignalHandler(int)
{
    qDebug() << __FUNCTION__ << 0;

#if 0
    QMutexLocker locker(&mMutex);
#else
    if (!enable)
        return;
#endif

    enable = false;

    char a = 1;
    ::write(mSocketFd[0], &a, sizeof(a));

    qDebug() << __FUNCTION__ << 1;
}

void PanelDriver::qtSignalHandler()
{
    qDebug() << __FUNCTION__ << 0;
    mSocketNotifier->setEnabled(false);
    qDebug() << __FUNCTION__ << 1;
    char tmp;
    ::read(mSocketFd[1], &tmp, sizeof(tmp));
    qDebug() << __FUNCTION__ << 2;

    // do Qt stuff
    static int cnt = 0;
    qDebug() << __FUNCTION__ << cnt++;
    emit panelChanged();
    qDebug() << __FUNCTION__ << 3;

    mSocketNotifier->setEnabled(true);
    qDebug() << __FUNCTION__ << 4;

    enable = true;
}

tovax

If there is no sleep, the socket can work at any fast speed, which I have been testing for some time ago. Now I want to refresh qcharts in timerEvent, which caused the application to freeze.

tovax

Perform a write test on the socketpair. Each time, 278 (0~277) pieces of data are written and then frozen.

int cnt = 0;
while (true) {
    char a = 1;
    ::write(mSocketFd[0], &a, sizeof(a));
    qDebug() << __FUNCTION__ << cnt++;
}

debug output:

PanelDriver 0
PanelDriver 1
PanelDriver 2
PanelDriver 3
... ... ...
PanelDriver 273
PanelDriver 274
PanelDriver 275
PanelDriver 276
PanelDriver 277

tovax

It may not be caused by the socket write buffer being full. It seems that after the socket was written, the activate() signal was not triggered, causing the socket to be unable to read in time, and then causing the socket write buffer to be full.

However, I have already processed all events in timerEvent, and I don't know why there is still a freeze. More strangely, from the debug output information, it can be seen that the exception occurred at the moment the timerEvent returned.

void PanelDriver::unixSignalHandler(int)
{
    qDebug() << __FUNCTION__ << 0;
    char a = 1;
    ::write(mSocketFd[0], &a, sizeof(a));
    mBufferCounter++;
    qDebug() << __FUNCTION__ << 1 << mBufferCounter;
}

void PanelDriver::qtSignalHandler()
{
    mSocketNotifier->setEnabled(false);

    char tmp;
    ::read(mSocketFd[1], &tmp, sizeof(tmp));
    mBufferCounter--;
    qDebug() << __FUNCTION__ << mBufferCounter;

    mSocketNotifier->setEnabled(true);
}

void JCDemoDriver::timerEvent(QTimerEvent *event)
{
    if (event->timerId() != mTimerId) {
        qDebug() << __FUNCTION__ << __LINE__;
        QWidget::timerEvent(event);
        return;
    }

    static int cnt = 0;
#if 0
    qDebug() << __FUNCTION__ << cnt++;
#else
    label->setText(QString::number(cnt++));
#endif
    int ms = 0;
    do {
        QThread::msleep(1);
        QCoreApplication::processEvents();
        if (ms % 10 == 0)
            qDebug() << __FUNCTION__ << ms;
    } while ((ms++) < 100);
    qDebug() << __FUNCTION__ << QTime::currentTime();
}

debug output:

timerEvent 0
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
timerEvent 10
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
timerEvent 20
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
timerEvent 30
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
timerEvent 40
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
timerEvent 50
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
timerEvent 60
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
timerEvent 70
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
timerEvent 80
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
timerEvent 90
unixSignalHandler 0
unixSignalHandler 1 1
qtSignalHandler 0
timerEvent 100
timerEvent QTime("11:12:00.360")
unixSignalHandler 0
unixSignalHandler 1 1
unixSignalHandler 0
unixSignalHandler 1 2
unixSignalHandler 0
unixSignalHandler 1 3
unixSignalHandler 0
unixSignalHandler 1 4
unixSignalHandler 0
unixSignalHandler 1 5
unixSignalHandler 0
unixSignalHandler 1 6
unixSignalHandler 0
unixSignalHandler 1 7
unixSignalHandler 0
unixSignalHandler 1 8
unixSignalHandler 0
unixSignalHandler 1 9
unixSignalHandler 0
unixSignalHandler 1 10
... ... ... ... ... ... ...
unixSignalHandler 0
unixSignalHandler 1 273
unixSignalHandler 0
unixSignalHandler 1 274
unixSignalHandler 0
unixSignalHandler 1 275
unixSignalHandler 0
unixSignalHandler 1 276
unixSignalHandler 0
unixSignalHandler 1 277
unixSignalHandler 0
unixSignalHandler 1 278
unixSignalHandler 0
unixSignalHandler 0
unixSignalHandler 0
unixSignalHandler 0

tovax

It can be determined that the freezing of the application has nothing to do with the reading and writing of the socket. Because just setting the unix signal handler can also cause freezing.

tovax

@tovax said in Unix signals and QCharts cause application blocking:

It can be determined that the freezing of the application has nothing to do with the reading and writing of the socket. Because just setting the unix signal handler can also cause freezing.

After making unixSignalHandler() reentrant, socket write blocking is likely to be the main cause of freezing. I am testing and will update the github code in 12 hours.

JonB

@tovax said in Unix signals and QCharts cause application blocking:

socket write blocking is likely to be the main cause of freezing

Sockets do have a "backlog queue" for writes issued, just like for file writes. However you are only talking about maybe 5 separate 1 byte writes, I'd be surprised if that hit it. Unless there is a "special case" for needing the read from the first write before further writes go through.

tovax

@JonB
After 15 hours of testing, running socketpair in the thread pool will not freeze the application (git commit id: 74d295).

tovax

@JonB said in Unix signals and QCharts cause application blocking:

@tovax said in Unix signals and QCharts cause application blocking:

socket write blocking is likely to be the main cause of freezing

Sockets do have a "backlog queue" for writes issued, just like for file writes. However you are only talking about maybe 5 separate 1 byte writes, I'd be surprised if that hit it. Unless there is a "special case" for needing the read from the first write before further writes go through.

From the test results of these two days, I also believe that socket write blocking is not the real cause, but a result of other issues.

tovax

@tovax said in Unix signals and QCharts cause application blocking:

@JonB
After 15 hours of testing, running socketpair in the thread pool will not freeze the application (git commit id: 74d295).

Although using thread pools can temporarily solve this problem, I still don't know what the real reason is. Why does socketpair cause the application to freeze in the main thread. My feeling is that when a timerEvent returns, due to the fact that the sleep time is greater than the timing period, the application's handling of other events (such as unixSignalHandler) has any particularity. But I don't know how to test this assumption.
The reason I'm assuming this is that when executing QCoreApplication:: processEvents() while sleeping in timerEvent, there seems to be no problem. When socketpair is running in the main thread, the following test code in timerEvent)() can produce completely different results.

#if 1
    /* Will not freeze */
    int ms = 0;
    do {
        QThread::msleep(1);
        QCoreApplication::processEvents();
        if (ms % 20 == 0)
            qDebug() << __FUNCTION__ << ms;
    } while ((ms++) < 200);
#else
    /* Causes the application to freeze */
    QThread::msleep(200);
#endif