Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct
QCamera::stop hangs or causes a crash. How to deinit the camera properly?
Violet Giraffe last edited by Violet Giraffe
My program connects to the camera (
QCamera::start()), receives one viewfinder frame (via a custom
QAbstractVideoSurfacesublcass with overridden
presentmethod), and then disconnects from the camera (by calling
stopand then deleting the camera object).
One of two things happen: either the
stopcall freezes indefinitely, or access violation occurs deep inside Qt multimedia after calling
QCamera::~QCamera()(but not directly through the destructor; something goes wrong afterward in some event handler). This is on Windows. Here's the link to the project's repository for testing.
What's the problem?
stop()may be a non-blocking call and deleting the
QCameraimmediately is a mistake. I've tried calling
stop, but it didn't fix the problem. So how to delete
QCameraproperly and safely?
One of two things happen: either the stop call freezes indefinitely, or access violation occurs deep inside Qt multimedia after calling QCamera::~QCamera() (but not directly through the destructor; something goes wrong afterward in some event handler).
I don't have a windows to test, but the stack trace of the crash may be useful.
I suspect stop() may be a non-blocking call and deleting the QCamera immediately is a mistake. I've tried calling unload after stop, but it didn't fix the problem. So how to delete QCamera properly and safely?
If you're correct in your suspicion, you can delete the camera through an event, try:
That doesn't explain
stophanging, though. Probably a lock of some kind.
That doesn't explain stop hanging, though. Probably a lock of some kind.
It may be, it also might be a bug, or some idiosyncrasy of the Windows' backend. I have no reference for comparison, so I can't know.
Btw, you're intercepting the
_displayWidget's paint event, but you're not stopping its propagation, is this intended?
No, that's a mistake. Good catch, thank you.
Good catch, thank you.
No problem. Do consider interrupting the runtime when you get
stop()to hang and extracting the stack. It may attract some better answers.
Here's the crash stack:
Of course, the moment I decided I'm going to capture the stack of the freeze I lost the ability to reproduce it.
t3685 last edited by
Are you deleting the QCamera object in slot connected to signal that was thrown by the camera?
It appears the event loop is crashing, I can't see any reference to your code in that trace (except the trivial
_camera = std::make_shared<QCamera>(cameraInfo);
Looks suspicious. Qt has its own ownership system for
QObjectsubclasses, so this shared pointer could be deleting the camera based on you "not using" the camera anymore, while there's a scheduled event somewhere in the event loop still referencing the object. I suggest dropping that line and using a raw pointer (or better yet
QPointer) to track the object's lifetime.
I'm deleting it in a slot connected to QAbstractVideoSurface::present(). Now that I think about it, it may well be, in turn, called from QCamera. I will investigate.
Qt has its own ownership system for
It does have an ownership system, but not reference counting. Raw pointers are raw pointers. I might have to use
deleteLater, though, but it's not documented in any QCamera samples I've seen.
It does have an ownership system, but not reference counting.
It has parent-child system instead; no need for reference counting, as there can't be
QObjectcopying anyway. Additionally, Qt provides (as already mentioned) guarded pointers to
QObjects, so reference counting becomes unnecessary. By giving a parent to a
QObjectyou ensure the memory will be freed. And while it's generally possible to just
QObject@t3685's question is relevant - you can't do it from inside a slot. My advice is to post a deferred delete through
QObject::deleteLater(and keep your camera pointer in a
QPointernot STL shared one).
a slot connected to present? Can you tell more about that ?
In any case, deleting a camera from a QAbstractVideoSurface doesn't sound like a good idea. What happens usually is that your camera backend receives a QAbstractVideoSurface to paint images on.
Yes, I don't know the specific chain of events that lead to a crash, but I'm certain that deleting the
QCameraobject from a slot connected to
presentwas the cause of the problem.
I didn't exactly fix it, instead I decided to keep the QCamera object and
unloadit instead of
delete. Makes more sense since I know I always need to connect to the same camera, might as well avoid constructing it from scratch every time.
What I have is a custom
present(const QVideoFrame& frame)method overridden. It takes the frame, converts it to
QImageand emits it in a signal. The image is then displayed and analyzed to take different actions. I hate having to reject the the native
QCameraViewfinderwidget entirely (which probably uses OpenGL for fast rendering) and use the slow
QPainter::drawImage, but I didn't find any other way to intercept the viewfinder frames other than
QCameraViewfinderwidget, which is also an odd method that I don't like.
What about QVideoProbe ?
Isn't implemented for QCamera on Windows.