Skip to content

autoware_tensorrt_vad: vad_node segfaults on first TF miss (dangling temporary clock in RCLCPP_ERROR_THROTTLE) #13269

Open

Description

@germanros1987

Description

autoware_tensorrt_vad's CoordinateTransformer::lookup_base2cam() crashes the whole vad_node with SIGSEGV the first time a TF lookup fails, instead of logging the error it was trying to report.

The catch block passes a temporary clock to the throttle macro
(e2e/autoware_tensorrt_vad/lib/coordinate_transformer.cpp:55-57 on main):

} catch (const tf2::TransformException & ex) {
  RCLCPP_ERROR_THROTTLE(
    rclcpp::get_logger("autoware_tensorrt_vad"), *rclcpp::Clock::make_shared(), 5000,
    ...

RCLCPP_ERROR_THROTTLE binds its clock argument to a reference inside the macro expansion and then calls .now() on it in a later statement. *rclcpp::Clock::make_shared() dereferences a temporary shared_ptr whose only reference dies at the end of that first statement — C++ lifetime extension does not apply to *sp (it is an lvalue referring to the managed object, not a prvalue), so the Clock is destroyed before the macro uses it. The subsequent now() call is a use-after-free.

Impact

  • Any transient TF miss at startup (e.g. a camera frame_id published before the sensor-kit TF tree is complete, or a frame_id not present in the URDF) kills the node with exit code -11.
  • Because the crash happens inside the error path, the intended "Failed to get TF transformation" message is never printed — the node just dies silently, which makes the underlying TF problem unnecessarily hard to diagnose.

Reproduction

  1. Launch VAD (use_e2e_planning:=true e2e_planning_type:=vad) with any camera whose camera_info.header.frame_id has no transform from base_link (one misnamed frame is enough).
  2. vad_node exits with process has died ... exit code -11 on the first frame, with no error log.
  3. Re-running the exact vad_node command line from the death message under gdb -batch -ex run -ex bt shows the segfault in the clock use inside the throttle macro expansion in lookup_base2cam.

Reproduced on 0.52.0 + the VAD PR (#1685-based setup) with ROS 2 Jazzy; the same code is present on main today.

Suggested fix

Keep a clock alive for the macro, e.g.:

} catch (const tf2::TransformException & ex) {
  static const rclcpp::Clock::SharedPtr error_clock = rclcpp::Clock::make_shared();
  RCLCPP_ERROR_THROTTLE(
    rclcpp::get_logger("autoware_tensorrt_vad"), *error_clock, 5000,
    "Failed to get TF transformation: %s -> %s. Reason: %s", source_frame.c_str(),
    target_frame.c_str(), ex.what());
  return std::nullopt;
}

(or plumb the node's clock into CoordinateTransformer, which also makes the throttle honor sim time). We have been running the static variant in a CARLA-simulator integration and it both stops the crash and surfaces the intended TF error message. Happy to open a PR if the static approach is acceptable.

Activity

  1. stale commented on Oct 29, 2026

    @stale

    This pull request has been automatically marked as stale because it has not had recent activity.

  2. added
    status:staleInactive or outdated issues. (auto-assigned)
    on Oct 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    status:staleInactive or outdated issues. (auto-assigned)

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions