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

[shoumikhin]

The problem

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(t_dst.mutable_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:

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

Nothing points at the cause, 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 naming the fix instead of
crashing:

Cannot copy into a memory-planned tensor that does not live on the host:
destination device type 1, source device type 0. A program whose activations
stay on a device must be exported with MemoryPlanningPass(alloc_graph_input=False)
so the runtime shares the caller's memory instead of copying into its own buffer.

This does not make that copy work, on purpose. A caller who hands over device memory
asked for no copying, so the right answer is to export the program so the runtime shares
that memory rather than duplicating it. The message says how.

Host to host copying is unchanged, which is every existing caller.

Test plan

Added copy_tensor_data_device_test.cpp, covering three cases with no GPU needed, since
a tensor only has to be labelled as device memory for the check to apply:

• a host to host copy still succeeds and the data moves
• a device destination is refused instead of copied into
• a device source is refused as well

Verified the error text is produced rather than a crash. Built and ran the runtime tests
on Linux x86_64.

[shoumikhin]

Stack from ghstack (oldest at bottom):

• -> Report a clear error instead of crashing on a device-planned copy #21704
• Document and test the memory planning a device-activation export needs #21703

[pytorch-bot]

🔗 Helpful Links

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

• 📄 Preview Python docs built from this PR

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

❌ 8 New Failures, 2 Unrelated Failures

As of commit cbcf910 with merge base 730b77a ():

NEW FAILURES - The following jobs have failed:

• Lint / lintrunner (gh)
  >>> Lint for runtime/core/exec_aten/util/test/copy_tensor_data_device_test.cpp:
• pull / test-vulkan-operators-linux / linux-job (gh)
  /pytorch/executorch/runtime/core/exec_aten/util/test/copy_tensor_data_device_test.cpp:45:9: error: no member named 'TensorShapeDynamism' in namespace 'executorch::runtime::etensor'; did you mean 'executorch::runtime::TensorShapeDynamism'?
• pull / unittest / linux / linux-job (gh)
  /pytorch/executorch/runtime/core/exec_aten/util/test/copy_tensor_data_device_test.cpp:45:9: error: no member named 'TensorShapeDynamism' in namespace 'executorch::runtime::etensor'; did you mean 'executorch::runtime::TensorShapeDynamism'?
• pull / unittest / macos / macos-job (gh)
  /Users/ec2-user/runner/_work/executorch/executorch/pytorch/executorch/runtime/core/exec_aten/util/test/copy_tensor_data_device_test.cpp:45:9: error: no member named 'TensorShapeDynamism' in namespace 'executorch::runtime::etensor'; did you mean 'executorch::runtime::TensorShapeDynamism'?
• pull / unittest-buck / linux / linux-job (gh)
  runtime/core/exec_aten/util/test/copy_tensor_data_device_test.cpp:45:9: error: no member named 'TensorShapeDynamism' in namespace 'executorch::runtime::etensor'; did you mean 'executorch::runtime::TensorShapeDynamism'?
• pull / unittest-buck / macos / macos-job (gh)
  runtime/core/exec_aten/util/test/copy_tensor_data_device_test.cpp:45:9: error: no member named 'TensorShapeDynamism' in namespace 'executorch::runtime::etensor'; did you mean 'executorch::runtime::TensorShapeDynamism'?
• pull / unittest-editable / linux / linux-job (gh)
  /pytorch/executorch/runtime/core/exec_aten/util/test/copy_tensor_data_device_test.cpp:45:9: error: no member named 'TensorShapeDynamism' in namespace 'executorch::runtime::etensor'; did you mean 'executorch::runtime::TensorShapeDynamism'?
• pull / unittest-editable / macos / macos-job (gh)
  /Users/ec2-user/runner/_work/executorch/executorch/pytorch/executorch/runtime/core/exec_aten/util/test/copy_tensor_data_device_test.cpp:45:9: error: no member named 'TensorShapeDynamism' in namespace 'executorch::runtime::etensor'; did you mean 'executorch::runtime::TensorShapeDynamism'?

FLAKY - The following jobs failed but were likely due to flakiness present on trunk:

• pull / unittest / windows / windows-job (gh) (detected as infra flaky with no log or failing log classifier)
• pull / unittest-editable / windows / windows-job (gh) (detected as infra flaky with no log or failing log classifier)

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

[shoumikhin]

Superseded by #21960.

Two reasons for reopening this as a standalone change:

It did not build. copy_tensor_data_device_test.cpp named
executorch::runtime::etensor::TensorShapeDynamism, but that enum lives in
executorch::runtime and is aliased into executorch::aten, never into etensor. That
broke unittest, unittest-buck and unittest-editable on Linux, macOS and Windows. It
is fixed in #21960.

It did not need to be stacked. This change touches runtime/core/exec_aten/util/ and
#21703 touches exir/passes/ and exir/tests/, with no overlap, so the stacking was
positional rather than a real dependency. #21960 sits directly on main and can be
reviewed and landed on its own.

#21960 also strengthens the new test. It previously handed one buffer to both the source
and the destination, so the host-to-host case was a self-copy and asserted only the
returned Error; deleting the copy would not have failed it. Each tensor now owns its
storage and the test checks the data arrives.

[shoumikhin]

Closing in favor of #21960, which is green: the unittest jobs on Linux, macOS and Windows all pass, in CMake, buck and editable installs. Those are the jobs that failed here.