Segfault with non zero camera_timeout_value_ms

[Matgothmog]

I have a pi5 using the official global shutter camera (imx296) in external synch mode.
My config file was setting camera_timeout_value_ms to 10000, but since the v0.7.1 libcamera segfaults when starting a recording (in external synch mode).
My code with the same config works with libcamera v0.7.0. It's only when I set the camera_timeout_value to 0 that the segfault does not occur, it's probably linked to the changes of the yaml parser ...

[naushir]

Would you be able to provide a callstack showing where the segfault occurs?

Also, can you specify the exact command and external setup used so we can attempt to recreate this at our end?

[Matgothmog]

I have a pi pico that sends pulses to the xvs pin of the global shutter camera following this documentation https://www.raspberrypi.com/documentation/accessories/camera.html#external-trigger.
I run at 60 hz with a shutter of time of 5000 micro seconds. The global shutter camera is connected to a pi5 running PI OS Lite.

Installed package versions:

• libcamera0.7=0.7.1+rpt20260429-1
• libpisp1=1.5.0-1
• python3-picamera2=0.3.36-1

Here is my test code (this code is working with libcamera v0.7.0 and libpisp 1.4.0)

repro_libcamera_071_segfault.py

[Matgothmog]

Here is the callstack of the code.

If I understand this correctly, it crashes in src/libcamera/pipeline/rpi/common/pipeline_base.cpp::CameraData::loadPipelineConfiguration in this for loop :

if (config_.cameraTimeoutValue) {
      /* Disable the IPA signal to control timeout and set the user requested value. */
      ipa_->setCameraTimeout.disconnect(); <- crashes on this
      frontendDevice()->setDequeueTimeout(config_.cameraTimeoutValue * 1ms);
  }

ipa seems to be a nullptr.

I let it in your hands.

Thanks for the quick reply !

libcam_071_segfault.txt

[naushir]

@njhollinghurst would you be able to try this out quickly to see if we can reproduce?

[njhollinghurst]

Yes, can reproduce this both with Picamera2 and with rpicam-hello when LIBCAMERA_RPI_CONFIG_FILE is set (it would otherwise not use this file). Bug appears between v0.7.0+rpt20260205 and v0.7.1+rpt20260429

[njhollinghurst]

Culprit probably: cc74afc

Sadly, the "obvious" fix of loading the IPA first, only gets us one line further, as frontendDevice's V4L2Device is also uninitialized.

Moving the call to data->loadPipelineConfiguration(); back to its original position below platformRegister() does seem to fix it, but that might break the change for frame rate configuration?

@davidplowman

[davidplowman]

Yes, the loadPipelineConfiguration() is called before the IPA is initialised so that the minControllerFrameDuration can be read from the yaml file and passed into the IPA at initialisation.

Unfortunately, when loadPipelineConfiguration() spots a non-zero camera_timeout_value_ms, it tries to do something with the IPA, which is now not initialised. Kaboom.

Easiest fix: don't do anything about the camera_timeout_value_ms in loadPipelineConfiguration(), just do it a bit later in the caller, once the IPA is available. But you could argue this slightly spreads the effect of that parameter around the code, in a not very elegant way.

An alternative: maybe add another parameter to the IPA saying whether to set up this signal or not. This could then be passed into its initialisation function. A slightly bigger change because the IPA and mojom files would also need editing.

Thoughts? Any other opinions?

Other moral of the story: we need to add a routine test for this, such as

import os
import json
from picamera2 import Picamera2, Platform

CONFIG_FILE = "test_config.yaml"
PLATFORM = "pisp" if Picamera2.platform == Platform.PISP else "vc4"

config = {
    "version": 1.0,
    "target": PLATFORM,
    "pipeline_handler": {
        "camera_timeout_value_ms": 100
    }
}

with open(CONFIG_FILE, 'w') as f:
    json.dump(config, f)

os.environ["LIBCAMERA_RPI_CONFIG_FILE"] = CONFIG_FILE

picam2 = Picamera2()

[njhollinghurst]

The simple fix LGTM.

I wonder if there is any need to generalize it (to include other "late" configurations, if we add any more of those in future) into a separate call? Probably not.