Solved 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" -
-
you need to show your code where qprocess starts.
also try gdb to see if your app crashes at the same spot. -
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.
-
@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.
-
@JoeCFD
Another tool to check memory issue is asan. Add this to your cmake
set( CMAKE_CXX_FLAGS_DEBUG "-g -fsanitize-recover=address -fsanitize=address" CACHE STRING "compile flags" FORCE )
try it out as well. -
-
@ocgltd I tried valgrind under Fedora 38 and the problem remains...
-
@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
-
-
@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.