App crash during valgrind, on QProcess::start
-
wrote on 22 Oct 2021, 17:16 last edited by ocgltd
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"
-
wrote on 10 Aug 2022, 20:03 last edited by
-
wrote on 22 Oct 2021, 17:23 last edited by
you need to show your code where qprocess starts.
also try gdb to see if your app crashes at the same spot. -
wrote on 22 Oct 2021, 18:26 last edited by ocgltd
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)
wrote on 22 Oct 2021, 18:55 last edited by JoeCFD@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.
-
wrote on 10 Aug 2022, 17:49 last edited by JoeCFD 8 Oct 2022, 17:49
@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.
wrote on 10 Aug 2022, 19:03 last edited by ocgltd 8 Oct 2022, 19:46@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
-
wrote on 10 Aug 2022, 20:03 last edited by
-
wrote on 10 Aug 2022, 20:08 last edited by
@JoeCFD Well that sure looks similar, so I'll chalk it up to a Qt bug for now. My app does lots of forking, so hard to temporarily disable this (to test for other leaks). So I'll just have to wait until this is fixed and recheck for leaks later.