Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

TensorFlow image classification tests running out of memory on Linux x64

Open Beginner friendly
  • Is something wrong?
#7,836 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 2 days

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
62/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp, linux, tensorflow
Domain
machine-learning, testing

Research direction

Start with the six TensorFlow image-classification training methods and their test attributes in the TensorFlow test project, then check how platform and build configuration conditions are applied to nearby tests. Quarantine the training methods as a group for Linux x64 local runs and both Debug and Release configurations, preserving other TensorFlow tests and platforms. Done means the specified training cases are skipped on Linux x64 while the remaining tests stay enabled.

Written by the indexing model from the issue text.

Description

area-TensorFlow untriaged

System Information (please complete the following information):

  • OS & Version: Ubuntu 22.04 and CentOS Stream 9 x64 Helix containers.
  • ML.NET Version: PR #7833, commit 100af589f.
  • .NET Version: .NET 8, Debug and Release.

Describe the bug
Accurate native-library detection enables previously skipped TensorFlow tests. The process exits with code 137 during TensorFlowImageClassificationWithExponentialLRScheduling in Release and TensorFlowImageClassificationBadImages in Debug. Debug logs report peak memory up to 7.2 GB. An OOM kill is suspected, not kernel-confirmed.

Screenshots, Code, Sample Projects
Ubuntu Debug log · Ubuntu Release log

Additional context
Temporarily quarantine the six image-classification training methods (10 test cases) as a group on Linux x64, including local runs and both build configurations. This covers default training, architecture variants, learning-rate scheduling, early stopping, and bad images. Keep non-training TensorFlow tests and other platforms enabled.

Reproduced outside Helix in Ubuntu 22.04 WSL x64 with the original Release binaries, .NET 8.0.16 and two CPUs: at a 16 GiB limit, 36 tests passed with 2 existing skips (peak RSS about 14.2 GiB). At an experimental 8 GiB limit, the kernel OOM-killed dotnet during BadImages. This does not establish the actual Helix memory limit. Memory retention across tests may contribute, so individual skips may only move the failure later.

The two initial skips were honored, but build 1643911 was killed later in TensorFlowImageClassification or TensorFlowImageClassificationEarlyStopping (Ubuntu Release log). The latest payload also OOM-kills at 8 GiB in WSL. Enabling the existing per-test GC option did not prevent the OOM, so that experiment was reverted.

With the training-group quarantine, the same 8 GiB WSL reproduction completes successfully: 26 passed and 8 reported skips (6 training methods plus 2 existing model-unavailable skips), with peak RSS about 1.26 GiB. The two quarantined theories cover multiple data rows. Linux CI still needs to rerun; this is a temporary coverage reduction, not a fix for the memory retention.

Dominant language
C#
Stars
9.4k
Forks
2k
Avg merge
3d 3h
Merged PRs (30d)
51

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from dotnet/machinelearning

All issues in dotnet/machinelearning

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.