Skip to content

fix: Do not mutate shared _gemm_output_3d in CpuGemmConv2d::run()#1275

Open
morgolock wants to merge 1 commit intomainfrom
pr/fix_shared_tinfo_cpugemm
Open

fix: Do not mutate shared _gemm_output_3d in CpuGemmConv2d::run()#1275
morgolock wants to merge 1 commit intomainfrom
pr/fix_shared_tinfo_cpugemm

Conversation

@morgolock
Copy link
Copy Markdown
Contributor

CpuGemmConv2d::run() was mutating the shared member _gemm_output_3d by extending its padding before soft_init()/import_memory().

When the same operator instance is reused across runs, this can cause later extend_padding() calls to fail. It is also unsafe when the operator is used from multiple threads.

Use a local TensorInfo copy in run() for padding extension and soft_init()/import_memory(), leaving _gemm_output_3d unchanged.

Added a new test: RepeatedRunDoesNotReuseImportedGemm3dTensorInfo.

Change-Id: I3e4e2d25cabf85724ecf126b1c93df6733ee7d48

CpuGemmConv2d::run() was mutating the shared member _gemm_output_3d by
extending its padding before soft_init()/import_memory().

When the same operator instance is reused across runs, this can cause
later extend_padding() calls to fail. It is also unsafe when the operator
is used from multiple threads.

Use a local TensorInfo copy in run() for padding extension and
soft_init()/import_memory(), leaving _gemm_output_3d unchanged.

Added a new test: RepeatedRunDoesNotReuseImportedGemm3dTensorInfo.

Change-Id: I3e4e2d25cabf85724ecf126b1c93df6733ee7d48
Signed-off-by: Pablo Marquez Tello <pablo.tello@arm.com>
@morgolock morgolock force-pushed the pr/fix_shared_tinfo_cpugemm branch from f823e19 to a1d5f71 Compare April 2, 2026 15:24
* - The second run does not throw
* - Both runs compute the same output
*/
TEST_CASE(RepeatedRunDoesNotReuseImportedGemm3dTensorInfo, framework::DatasetMode::ALL)
Copy link
Copy Markdown
Contributor

@gunes-arm gunes-arm Apr 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this really failing w/o this fix? I've been testing it but couldn't make it fail. I think it's happening because TensorAllocator's destructor is marking the TensorInfo as resizable again and when run() finishes the allocator that's been soft initialized is destructed and it marks the information object resizable again. This makes this problem only visible in situations where the usage of the same object is multi-threaded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants