From patchwork Tue Sep 9 13:12:37 2025 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= X-Patchwork-Id: 24298 Return-Path: X-Original-To: parsemail@patchwork.libcamera.org Delivered-To: parsemail@patchwork.libcamera.org Received: from lancelot.ideasonboard.com (lancelot.ideasonboard.com [92.243.16.209]) by patchwork.libcamera.org (Postfix) with ESMTPS id E4D0DC324E for ; Tue, 9 Sep 2025 13:12:44 +0000 (UTC) Received: from lancelot.ideasonboard.com (localhost [IPv6:::1]) by lancelot.ideasonboard.com (Postfix) with ESMTP id B8FDB6934B; Tue, 9 Sep 2025 15:12:43 +0200 (CEST) Authentication-Results: lancelot.ideasonboard.com; dkim=pass (1024-bit key; unprotected) header.d=ideasonboard.com header.i=@ideasonboard.com header.b="CVJgbTKn"; dkim-atps=neutral Received: from perceval.ideasonboard.com (perceval.ideasonboard.com [213.167.242.64]) by lancelot.ideasonboard.com (Postfix) with ESMTPS id 41CD86934B for ; Tue, 9 Sep 2025 15:12:41 +0200 (CEST) Received: from pb-laptop.local (185.221.142.115.nat.pool.zt.hu [185.221.142.115]) by perceval.ideasonboard.com (Postfix) with ESMTPSA id B55FB605; Tue, 9 Sep 2025 15:11:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ideasonboard.com; s=mail; t=1757423487; bh=Ox2z/AgDHLmy5Ij8/QGKdKF5aHDktkaOWvg/iolJo20=; h=From:To:Subject:Date:From; b=CVJgbTKnIikVmMWeNaGJx4+T7rv1Q6dgyPsIgE9NkLBGc4S2kHynr1fkh5Am2ZQAT ZDewQ0g1PjLSWfeHwiNt8C5TetYu94X/AG0HfMERVtTdaUaOLNhxn0At/gq1234I/f taGmy3J+y/TEFp5z62CW4Jcr68FYEdpRvXAWTA8g= From: =?utf-8?q?Barnab=C3=A1s_P=C5=91cze?= To: libcamera-devel@lists.libcamera.org, Nicolas Dufresne , Umang Jain Subject: [RFC PATCH v1] gstreamer: Be prepared when queueing request Date: Tue, 9 Sep 2025 15:12:37 +0200 Message-ID: <20250909131237.1344483-1-barnabas.pocze@ideasonboard.com> X-Mailer: git-send-email 2.51.0 MIME-Version: 1.0 X-BeenThere: libcamera-devel@lists.libcamera.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libcamera-devel-bounces@lists.libcamera.org Sender: "libcamera-devel" The moment execution enters `Camera::queueRequest()`, an application must be prepared to received the corresponding `requestCompleted` signal. However, the gstreamer element is currently not prepared: it queues the request, takes a lock, then inserts into a list. If the request completion handler acquires the lock right after the queueing, then it will not find the object in the list that it expects. Even potentially encountering an empty list, running into undefined behaviour when trying to pop from it. Fix that by queueing the request after the lock protected insertion. Bug: https://bugs.libcamera.org/show_bug.cgi?id=238 Fixes: 06bd05beced313 ("gstreamer: Use dedicated lock for request queues") Signed-off-by: Barnabás Pőcze --- Doing it while holding the lock is not ideal, but the alternative is getting a raw pointer to the `Request` object beforehand, but that does not seem too desirable either. --- src/gstreamer/gstlibcamerasrc.cpp | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) -- 2.51.0 diff --git a/src/gstreamer/gstlibcamerasrc.cpp b/src/gstreamer/gstlibcamerasrc.cpp index 79a025a57..103dfbca2 100644 --- a/src/gstreamer/gstlibcamerasrc.cpp +++ b/src/gstreamer/gstlibcamerasrc.cpp @@ -214,10 +214,10 @@ int GstLibcameraSrcState::queueRequest() } GST_TRACE_OBJECT(src_, "Requesting buffers"); - cam_->queueRequest(wrap->request_.get()); { GLibLocker locker(&lock_); + cam_->queueRequest(wrap->request_.get()); queuedRequests_.push(std::move(wrap)); }