Was there a change in QProcess::waitForReadyRead()?

Discuss anything related to product development
Post Reply
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Was there a change in QProcess::waitForReadyRead()?

Post by seasoned_geek »

Getting back into porting of Gede from Qt 5.x to CopperSpice. (Should have just started from scratch)

I'm not certain he knew exactly what he was doing, but what he had always worked under Qt. I've tracked the hang down to his readFromGdb() method.

Code: Select all

###### about to issue -file-list command

command() called with:  -file-list-exec-source-files 

 2.724| DEBUG | /home/roland/sf_projects/redbug/src/com.cpp:1300| # Cmd: '-file-list-exec-source-files'
text cmd being written:  -file-list-exec-source-files

Number of bytes written:  29 

call readFromGdb() in do-while loop

readFromGdb() called

m_result was not nullptr

onReadyReadStandardOutput() called 

returning because busy

onReadyReadStandardOutput() called 

returning because busy

onReadyReadStandardOutput() called 

returning because busy

onReadyReadStandardOutput() called 

returning because busy

onReadyReadStandardOutput() called 

returning because busy

 2.783| DEBUG | /home/roland/sf_projects/redbug/src/com.cpp:1090| row:^done,files=[{file="/home/roland/Projects/diamond/src/main.cpp",fullname="/home/roland/Projects/diamond/src/main.cpp"},{file="/usr/include/c++/9/bits/predefined_ops.h",fullname="/usr/include/c++/9/bits/predefined_ops.h"},{file="/usr/include/c++/9/typeinfo",fullname="/usr/include/c++/9/typeinfo"},{file="/usr/include/c++/9/new",fullname="/usr/include/c++/9/new"},{file="/usr/include/x86_64-linux-gnu/c++/9/bits/gthr-default.h",fullname="/usr/include/x86_64-linux-gnu/c++/9/bits/gthr-default.h"},{file="/usr/include/c++/9/ext/atomicity.h",fullname="/usr/include/c++/9/ext/atomicity.h"},{file="/usr/include/c++/9/bits/std_function.h",fullname="/usr/include/c++/9/bits/std_function.h"},{file="/usr/include/c++/9/bits/hashtable_policy.h",fullname="/usr/include/c++/9/bits/hashtable_policy.h"},{file="/usr/include/c++/9/bits/stl_algobase.h",fullname="/usr/include/c++/9/bits/stl_algobase.h"},{file="/usr/include/c++/9/bits/std_mutex.h",fullname="/usr/include/c++/9/bits/std_mutex.h"},{file="/usr/include/c++/9/mutex",fullnam
That response is horribly truncated. The response from the command line is hundreds, perhaps a thousand or more files in one continuous string. I have a file saved, not that it should be needed.

Brain is mush now. Will build the original Gede under Qt on Ubuntu 20.04 LTS to confirm suspiscion. I suspect under Qt 5.x readyRead isn't set until gdb finishes writing the entire string.

According to Pluma, when I paste that text into it, first byte is in column 1, hit the end key and says cursor is in 1089. Is 1090 a magic number anyone remembers? This is consistent. I've run it 3 times and it truncates right after "fullnam" every time.

It also looks like readyRead isn't being set for the earlier command response so it can be cleaned out.

Code: Select all

-file-list-exec-source-files
^done,files=[{file="/home/roland/Projects/diamond/src/main.cpp",fullname="/home/roland/Projects/diamond/src/main.cpp"},{file="/usr/include/c++/9/bits/predefined_ops.h",fullname="/usr/include/c++/9/bits/
When run from the command line the line starts as one would expect.

Just wanted to see if 1090 rang any bells.
ansel
Posts: 152
Joined: Fri Apr 10 2015 8:23 am

Re: Was there a change in QProcess::waitForReadyRead()?

Post by ansel »

In the API docs for readyRead() the signal is emitted "once every time new data is available for reading from the device." This signal does not indicate that all the data is available. If you want to know when the process has closed and all the data is available, connect the readChannelFinished() signal to a slot in your code.

Applications can expect that every time readyRead() is emitted some amount of data is available for reading. There are no guarantees about how much data will be read or what the boundaries between the sections will be.
Ansel Sermersheim
CopperSpice Cofounder
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: Was there a change in QProcess::waitForReadyRead()?

Post by seasoned_geek »

Ansel,

Thank you for responding.

I'm fully aware of what the documentation says.

This isn't a "random timing bug." The application I'm porting compiles and runs just fine with Qt 4.x all the way up to the version of Qt 5 in the Ubuntu 20.04 LTS repos.

This isn't a random amount of data and the read is happening in a loop. It gags __exactly__ after transferring 1089 characters each and every time. It appears CopperSpice, somewhere in the path, has a buffer limit of 1090 (allowing for one NULL byte).

I will put together a stand alone demo of the problem. It is either in the I/O logic of the QProcess class or whatever the code is using to read the fake terminal.
Cmd: '-inferior-tty-set /dev/pts/4'

I haven't done much with this hunk of code so I don't even know what they are using. I just know it works flawlessly on all versions of Qt tried and completely fails when built with CopperSpice.

Back when I have code to post or link to.
seasoned_geek
Posts: 254
Joined: Thu Jun 11 2020 12:18 pm

Re: Was there a change in QProcess::waitForReadyRead()?

Post by seasoned_geek »

sigh....

Kids these days

There is a com problem between QProcess and the application. It doesn't exist when built with Qt. Silly me thought it safe to use the built in debug and error message routines to track this down.

Code: Select all

void debugMsg_( const char *filename, int lineNo, const char *fmt, ... )
{
    va_list ap;
    char buffer[1024];
    QTime curTime = QTime::currentTime();

    QMutexLocker locker( &r_mutex );

    va_start( ap, fmt );

    vsnprintf( buffer, sizeof( buffer ), fmt, ap );


    va_end( ap );

    printf( "%2d.%03d| DEBUG | %s:%d| %s\n",
            curTime.second()%100, curTime.msec(),
            filename, lineNo, buffer );
}

I hate other people's code.

Before I can find where the problem actually is I have to un-hose this.

Apparently one can go 65-bytes past the end of a char buffer without managing to get a stack dump. No telling what vsnprintf() did with the other 20+MEG. Must not pay attention to the sizeof() value either.
Post Reply