Error reading readAll StandardOutput()

[JoeCFD]

@e-ferro said in Error reading readAll StandardOutput():

QProcess process;

create a process pointer inside MainWindow
m_process = new QProcess;
delete it in the destructor

[e.ferro]

Using command:

process.startCommand("flashrom -p serprog:dev=/dev/ttyACM0:115200 -r /home/ti/Downloads/uno.rom ");

removing /bin/sh

the message stays

QProcess: Destroyed while process ("flashrom") is still running.

If I start with startDetached

The entire log of the operation appears in the Application Output but is not read by readAllStandardOutput()

[e.ferro]

@JoeCFD

Sorry, could you give me an example? I put it in the main window and it gives me an error

[JoeCFD]

@e-ferro

class MainWindow : public QMainWindow
{
... your stuff...
private:
QProcess * m_process{};
};

void MainWindow::on_pushButton_2_clicked(){
  if ( nullptr == _process ) {
      m_process = new QProcess;
  }
 
   m_process->start(...);
   if ( true == process->waitForFinished() ) {
       QString word = m_process->readAllStandardOutput();
       ui->textEdit->setText(word);
   }
}

[JonB]

@e-ferro said in Error reading readAll StandardOutput():

process.waitForFinished();

Let's establish what this is returning:

bool result = process.waitForFinished();
qDebug() << "waitForFinished:" << result;

Because it sounds like that is returning false, then the QProcess process would go out of scope while the process is still running and hence the error message.

One question: if you go into a terminal, type your flashrom -p ... command, I can see it runs up a UI. If you run this from a shell in a terminal, does the command complete immediately and show the next line's shell prompt while the UI is still being shown? If so that means in any case you cannot wait for flashrom to exit to indicate it has finished doing whatever reading/writing it does.

[e.ferro]

@JoeCFD @JonB Still the same error, look at the output running from Ubuntu terminal and running from Qt

[JoeCFD]

how long does it take to run your script? If long, throw it into a thread and set the time longer. The default time is 3s.

[SGaist]

There is no need for a thread. QProcess is asynchronous already so if the operation takes a long time, just exploit properly this asynchronous nature.

[JoeCFD]

@SGaist right. Simply set more seconds

if ( true == process->waitForFinished(10000 ) ) { /*add to 10s or more */
    QString word = process->readAllStandardOutput();
    ui->textEdit->setText(word);
}

[JonB]

@e-ferro
I asked for output of the result of process.waitForFinished(), which you do not show.

The answer looks quite simple anyway. You have never said how long it takes for the flashrom to run, till you see the QProcess: Destroyed while process ("/bin/sh") is still running message. If you had said "flashrom takes quite some time to run, and I see that message after 30 seconds", we would have known immediately.

bool QProcess::waitForFinished(int msecs = 30000) waits by default for 30 seconds for the sub-process to finish. If it has not finished by then it returns false (operation timed out) and then your code continues executing. When your code exits the on_pushButton_2_clicked() slot the QProcess process variable goes out of scope, and you will get that warning message because the sub-process is still running.

Assuming you want your Qt program to simply do nothing and wait until the flashrom application exits, you should call:

process.waitForFinished(-1);

Now you will get its complete output and not get that warning message.

Be aware that the user will not be able to do anything at all in your Qt application while it is waiting like this. I am guessing this is fine by you. If you do want the user be able to do other things in your app while flashrom is running, you would have to change to using signals and slots.

[e.ferro]

Now it works with the command

process.waitForFinished(-1);

The difference is that the log message only appears after the end of the process and the program is frozen, but it works perfectly. But now I put a message for the user to wait. Thanks a lot guys for the help!!

[SGaist]

Then as suggested before, you should take advantage of the asynchronous nature of QProcess so your users won't be in front of a frozen UI maybe a disabled one but not frozen.