Report a clear error instead of crashing on a device-planned copy

[shoumikhin]

Supersedes #21704, which was stacked and did not build. Same change, rebuilt on main
with the compile error fixed.

What is broken

When the runtime fills a memory-planned tensor it copies the caller's data into the
buffer it reserved, using a plain host copy:

std::memcpy(dst_data_ptr, t_src.const_data_ptr(), t_src.nbytes());

That is correct for main memory. If the destination lives on an accelerator, a host copy
into it is undefined and the process dies with a segmentation fault and no message. The
last thing a user sees is unrelated to the cause:

[cuda_backend.cpp:429] Created new CUDA stream 0x10ae920 for method
Segmentation fault (core dumped)

Nothing points at what actually went wrong, which is a program whose activations live on
a device being exported so the runtime also reserves its own buffer for them.

The change

Check the assumption the copy makes, and return an error that names the fix:

Planned-buffer copy needs host memory on both sides: dst device CUDA, src device CPU.
Export with MemoryPlanningPass(alloc_graph_input=False) to share the caller's memory.

Both the ATen and portable variants of copy_tensor_data get the same guard, so the
behaviour does not depend on which runtime is built.

The message is deliberately short. The runtime logs through a 256-character buffer
(runtime/platform/log.cpp), so a longer message is silently cut off, and the part that
tells a user what to change is the part worth keeping.

Test plan

A new test builds tensors tagged CPU and CUDA and checks three cases:

• host to host succeeds and the data arrives,
• a device destination is refused with Error::NotSupported,
• a device source is refused the same way.

Each tensor owns its own storage, so the host-to-host case has a distinct destination.
Deleting the copy makes that assertion fail, which is the point: a test that shares one
buffer between source and destination would pass whether or not the copy happened.

Verified by compiling the test against the portable headers and running the host-to-host
case with the copy present and then removed:

copy present -> pass
copy removed -> fail (4 assertions)

Known gap

The guard in the ATen variant has no test coverage. The new test is registered outside
the get_aten_mode_options() loop that the neighbouring tensor_util_test uses, and it
names executorch::runtime::internal::, which is executorch::runtime::aten::internal::
in ATen mode. The portable guard is covered; the ATen one is not. Worth fixing, and left
out of this change to keep it to one concern.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/21960

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

✅ No Failures

As of commit 62498f8 with merge base 3caaaca ():
💚 Looks good so far! There are no failures yet. 💚

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.