App crash during valgrind, on QProcess::start
-
Although my apps seems to run fine (on Fedora 34), I tried a valgrind to check for problems. Every time running in valgrind my app crashes on a syscall. Backtrace shows it is from QProcess::start. The parameters to the QProcess instance look fine. Can someone explain what is wrong and how I fix this?
Program crashes on last line below.
QProcess *command = new QProcess(); QProcessEnvironment oldenvironment = QProcessEnvironment::systemEnvironment(); command->setProcessEnvironment(oldenvironment); command->start(m_executableName, m_parameters);m_exectuableName is "which"
m_parameters contains "dmidecode"
-
I added my code to the question. Yes it crashes in gdb too (when running WITH valgrind). But, in debug mode alone it does not crash, and from command line with gdb it does not crash.
Is this a Fedora34 + valgrind issue? I've never encountered this type of problem before so unsure...
-
I added my code to the question. Yes it crashes in gdb too (when running WITH valgrind). But, in debug mode alone it does not crash, and from command line with gdb it does not crash.
Is this a Fedora34 + valgrind issue? I've never encountered this type of problem before so unsure...
-
@ocgltd valgrind runs very slow normally. Do you have any syn actions or updates or sort of multi-threading after process starts?
-
@JoeCFD I have other threads running, but this thread is blocked at the start method. Those other threads don't interact with this thread in any way....(not sure how to interpret your question)
@ocgltd not sure if the process needs any resources from somewhere else. If no, simply comment out this piece of code to run valgrind. The purpose of running valgrind is to find memory issues. If this process is a simple run and your code works fine, this part of the code will not cause any memory problem and you can simply ignore it.
-
@ocgltd not sure if the process needs any resources from somewhere else. If no, simply comment out this piece of code to run valgrind. The purpose of running valgrind is to find memory issues. If this process is a simple run and your code works fine, this part of the code will not cause any memory problem and you can simply ignore it.
-
@ocgltd not sure if the process needs any resources from somewhere else. If no, simply comment out this piece of code to run valgrind. The purpose of running valgrind is to find memory issues. If this process is a simple run and your code works fine, this part of the code will not cause any memory problem and you can simply ignore it.
-
@JoeCFD The data returned by this QProcess is actually important to the program. But I'll assume this is a valgrind + FC34 issue.
I'll try the same under Red Hat 7 in the near future and will update the thread.
-
@ocgltd
in the link I posted above. There is something like:
today I tried to run my sender process with QProcess::startDetached() and it worked without any problems.
Try it out. If it works, simply change it back if you prefer the process to be attached after valgrind run.I have a few processes running in my app and do not have this issue.
-
@ocgltd
in the link I posted above. There is something like:
today I tried to run my sender process with QProcess::startDetached() and it worked without any problems.
Try it out. If it works, simply change it back if you prefer the process to be attached after valgrind run.I have a few processes running in my app and do not have this issue.
@JoeCFD I tried using startDetached and my app still crashed at the same point. However, it dumped the stdout of my process to the terminal window, following by html tag structured valgrind output.
Another clue, is that after crashing valgrind reports:
syscall param waitid(infop) points to unaddressable byte(s)on the QProcess.start line
-
