#1554 multiplot freeze/crash with qt terminal

[Matthew Halverson]

The following procedure causes gnuplot 5.0 to freeze and force using the program not responding dialog box to close it on windows 7.

1) Make sure the terminal is set to qt
2) Type "set multiplot" and hit enter
3) Close the plot window that opens up
4) Type "unset multiplot" and hit enter

It isn't ideal to close that window without doing anything, but it can accidentally get closed, so this behavior should be prevented.

I have tested this with release candidate 2 (64bit) and release candidate 3 (32bit) as well as the final release (gp500-win32-mingw.zip) of the 32bit version dated 1/1/15 (which uses wxt as the default terminal, requiring the terminal to be changed to qt to create this bug). I've tried the wxt and windows terminals without problem, so it seems isolated to the qt terminal.

[Tatsuro MATSUOKA]

Confirmed 5.1.0 (CVS) on windows. However, similar error happed gnuplot 5.1.0 (CVS) on Ubuntu 14.04.
On gnuplot and wgnuplot on windows, the operation gave no messages.
On Ubuntu, the following message were displayed:

multiplot> unset multiplot
gnuplot> Event not swallowed ! 1038 
############### WRONG readEvent  29369344 137 
Error: gnuplot_qt socket not responding

[Tatsuro MATSUOKA]

Change the title because the phenomenon happenes also on Linux with qt terminal.

[Ethan Merritt]

But the error message is correct! Since the plot window has been closed, it cannot respond. That is exactly what the error message says.

If you then type a plot command, it will open up a new plot window and continue as normal. At least it does on linux; I don't know what happens on Windows.

[Tatsuro MATSUOKA]

However, for X11, unset multiplot after plot window is closed, prompt comes back
> gnuplot
but not hang up.

For wxt, unset multiplot after plot window is closed, prompt comes back
> gnuplot
and plot window appears again.

The behviors are inconsistent.

[Ethan Merritt]

Different terminals are different.
There are many ways in which x11 does not act identically to qt. wxt is different because only one process is involved, there is no separate program "gnuplot_wxt".

If Windows freezes when this happens, I agree it is a bug and should be fixed.
But printing an error message before continuing seems very reasonable to me.

The "Event not swallowed ! 1038" is useful for debugging.

The "############### WRONG readEvent xxx yyy" message is from gnuplot_qt. It does look a bit scary. Maybe it would be clearer to say "gnuplot_qt exiting on read failure".

"error: gnuplot_qt socket not responding" tells exactly what the problem is. Maybe it would be more friendly to say "error: gnuplot_qt connection to plot window not responding"?

[Tatsuro MATSUOKA]

"gnuplot_qt exiting on read failure" sounds good. But gnuplot_qt does not exit and remains without respose. I can only kill the terminal.

[Matthew Halverson]

It is indeed freezing under Windows (I havent tried under Ubuntu as the repository has a 4.x line version, and building from scratch seems a little intimidating to me). Printing an error message and continuuing is what reasonably should be happening instead of just freezing.

[Tatsuro MATSUOKA]

It seems that qDebug() does not represent anything to console on windows by default.
http://stackoverflow.com/questions/13431734/qt-qdebug-doesnt-work-in-windows-shell

I have not enough knowledge for qt so that I cannot go further at the moment. I need help from those who know well about qt for windows.

[Tatsuro MATSUOKA]

In qt_term.cpp, which is part of main program (gnuplot), qDebug() represent message to console on gnuplot.exe. (but not on wgnuplot.exe).

I have confirmed by quick hacking the code

231: #ifdef WIN32
232:    filename = QCoreApplication::applicationDirPath();
233:    qDebug() << "test2";
234: #else

If it is only representation problem, the message
Error: gnuplot_qt socket not responding
should be represented in because the above message is prepared in qt_term.cpp (gnuplot). Therefore on windows other problem might exist.

BTW, wgnuplot (and wgnuplot_pipes) has problem of representation of the messages.
qDebug() can be repseneted in console but not wgnuplot command windows.
This might be better to be cosidered separately.
I have posted related thread in gnuplot-beta ML.
gnuplot.10905.n7.nabble.com
http://gnuplot.10905.n7.nabble.com/qt-terminal-for-windows-qDebug-problems-td19677.html

[Tatsuro MATSUOKA]

I have grepped the source tree by keywords 'Event not swallowed'.
The results were
src/qtterminal/QtGnuplotEvent.cpp:186: else qDebug() << "Event not swallowed !" << type;

The above is part of function "void QtGnuplotEventReceiver::swallowEvent(QtGnuplotEventType type, QDataStream& in)"

// Catch events for which the receiver is not active
void QtGnuplotEventReceiver::swallowEvent(QtGnuplotEventType type, QDataStream& in)
{
    QPoint point;
    QString string;
    int i;
    bool b;

            if (type == GESetCurrentWindow) in >> i;        // 1000
    else if (type == GEInitWindow)       ;               // 1001
    else if (type == GECloseWindow)      in >> i;        // 1002
    else if (type == GEExit)             ;               // 1003
    else if (type == GEPersist)          ;               // 1004
    else if (type == GEStatusText)       in >> string;   // 1005
    else if (type == GETitle)            in >> string;   // 1006
    else if (type == GESetCtrl)          in >> b;        // 1007
    else if (type == GECursor)           in >> i;        // 1009
    else if (type == GEZoomStart)        in >> string;   // 1022
    else if (type == GEZoomStop)         in >> string;   // 1023
    else if (type == GERaise)            ;               // 1034
    else if (type == GEDesactivate)      ;               // 1038
    else if (type == GESetPosition)      in >> point;
    else qDebug() << "Event not swallowed !" << type;
}

Any suggestions?

[Tatsuro MATSUOKA]

I have checked out recent cvs source in which correction for this bug is included.
I have built on ubuntu 14.04.

Terminal type set to 'qt'
gnuplot> set multiplot
multiplot> unset multiplot
gnuplot> Event not swallowed ! 1038 
qt_gnuplot exiting on read error 
Error: plot window (gnuplot_qt) not responding - will restart

The gnuplot freezes in the last line but situation improved than before.
Thanks!

[Tatsuro MATSUOKA]

On windows, messages from codes of gnuplot_qt temorally to save files,
In QtGnuplotEvent.cpp

qDebug() << "qt_gnuplot exiting on read error";
else qDebug() << "Event not swallowed !" << type;

Both messages were saved to files after hack. Therefore it is just representation problem.
However, main program (qt_term.cpp)

Error: plot window (gnuplot_qt) not responding - will restart

does not appear.

This is different from those on Linux.

[Ethan Merritt]

The error message in the main program "not responding - will restart" is at line 982 in qt_term.cpp. But this is inside a section of code marked #ifndef WIN32 so it cannot be executed on Windows.

980            if (!(qt->socket.waitForReadyRead(-1))) {
981                    // Must be a socket error; we need to restart qt_gnuplot
982                    fprintf(stderr, "Error: plot window (gnuplot_qt) not responding - will restart\n");
983                    qt->gnuplot_qtStarted = false;
984                    return '\0';
985            }

It seems that the equivalent place in the Windows code is at line 1106

1106            qt->socket.waitForReadyRead(0);

I do not know why the code is different, but you could try replacing the Windows code with the same code used for linux. However I worry about this note in the Qt documentation:
http://doc.qt.io/qt-5/qabstractsocket.html#waitForReadyRead
Note: This function may fail randomly on Windows. Consider using the event loop and the readyRead() signal if your software will run on Windows.

[Matthew Halverson]

This bug is still present in windows under version 5.0.3 (using wgnuplot.exe). The following causes a freeze:

1. Issue set term qt
2. Issue set multiplot
3. Close the responding plot window
4. Issue unset multiplot

Interestingly, the following DOES NOT cause a freeze:

1. Issue set term qt
2. Issue set multiplot
3. Close the responding plot window
4. Issue plot sin(x)
5. Issue unset multiplot

Note that the plot sin(x) causes nothing to happen - the window does not reopen, but the following unset multiplot does not cause a freeze in this case.

[Tatsuro MATSUOKA]

Connfirmed on the current cvs verion of wgnuplot for windows.
For gnuplot.exe (console version), behavior is different in your second exapmle.

after
plot sin(x)

gnuplot hangs.

To correct the issue that you pointed out, a lot of knowledge of Qt for windows is required.
I have no ability and have not enough time.
Other experts are required to correct the issue.

[Ethan Merritt]

Is this problem fixed by the same patch applied for Bug #1753?
I.e. do not set the DeleteOnClose attribute of plot windows?

[Tatsuro MATSUOKA]

Your patch for Bug #1753 fixes the issue on windows here.
And I have just check out the latest cvs snapshot in which the bug #1753 fixed and built it.
The probrem here is also fixed.

[Tatsuro MATSUOKA]

Matthew Halverson

If you wolud like to the try fixed version, please try the following cvs snapshot
(51.0 development version)

http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

Thank for your bug reports

[Matthew Halverson]

I tested both the 32 bit and 64 bit and can confirm that the bug is fixed in that version both in gnuplot.exe and wgnuplot.exe.