Was there a change in QProcess::waitForReadyRead()?
Posted: Mon Feb 15 2021 11:01 pm
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.
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.
When run from the command line the line starts as one would expect.
Just wanted to see if 1090 rang any bells.
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
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/
Just wanted to see if 1090 rang any bells.