Sonar-python 5.24: OutOfMemoryError in flattenAmbiguousSymbols / AmbiguousSymbolImpl.copyWithoutUsag

SonarQube Cloud
1

ALM used: GitHub

CI system used: GitHub Actions (ubuntu-latest)

Scanner command used (private details masked):

GitHub Actions step

  • name: SonarCloud Scan
    uses: SonarSource/sonarqube-scan-action@v8.2.0
    env:
    SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
    SONAR_SCANNER_JAVA_OPTS: -Xmx5g

sonar-project.properties (relevant keys)

sonar.projectKey=
sonar.organization=
sonar.host.url=https://sonarcloud.io
sonar.python.version=3.12
sonar.sources=lambda,ui/src
sonar.tests=lambda,ui/src
sonar.test.inclusions=/tests//.py,**/.test.tsx,**/*.test.ts

tests, .venv, node_modules, dist, pycache excluded

Resolved runtime (from the scanner-status payload): SonarScanner CLI 8.1.0.6389, engine 13.4.0.3968, sonar-python 5.24.0.34324, Java 21.0.11 (Eclipse Adoptium).

Languages of the repository: Python (primary — this is where it crashes), plus TypeScript/JavaScript, CSS, and shell.

SonarCloud project URL: project is private, so no public URL. This is a push analysis on main (not a PR), so it’s unrelated to PR decoration.

Error observed:

Analysis reliably OOMs. The Python sensor stalls on a single file for ~3 minutes, then dies during project-level symbol table construction, while resolving a function parameter’s type annotation to an ambiguous symbol and recursively flattening/copying every candidate definition (and their members’ types, themselves ambiguous) with no apparent depth/cycle guard. Raising the heap only delays it — peak used was already ~6.0 GB against a 5 GB -Xmx cap.

Key metrics from the scanner-status payload: maxHeapBytes=5368709120 (5g), peakUsedHeapBytes=6450839552 (~6.0 GB), physicalMemoryBytes=8323981312, python plugin durationMs=206100, ncloc=111420.

java.lang.OutOfMemoryError: Java heap space
at org.sonar.python.semantic.SymbolUtils.flattenAmbiguousSymbols(na:3335)
at org.sonar.python.semantic.AmbiguousSymbolImpl.create(na:2550)
at org.sonar.python.semantic.AmbiguousSymbolImpl.copyWithoutUsages(na:1238)
at org.sonar.python.semantic.AmbiguousSymbolImpl.copyWithoutUsages(na:2137)
at org.sonar.python.semantic.ClassSymbolImpl.lambda$copyWithoutUsages$11(na:1719)
... (ClassSymbolImpl.copyWithoutUsages recurses 582 <-> 257 repeatedly) ...
at org.sonar.python.semantic.ClassSymbolImpl.copyWithoutUsages(na:582)
at org.sonar.python.semantic.SymbolUtils.typeshedSymbolWithFQN(na:2187)
at org.sonar.python.index.DescriptorUtils.setParameterType(na:105)
at org.sonar.python.index.DescriptorUtils.addParameters(na:1703)
at org.sonar.python.index.DescriptorUtils.createFunctionSymbol(na:1268)
at org.sonar.python.index.DescriptorUtils.symbolFromDescriptor(na:814)
at org.sonar.python.semantic.ProjectLevelSymbolTable.lambda$getSymbolsFromModule$12(na:151)

Steps to reproduce:

The repo is ~30 AWS-Lambda modules laid out flat / package-less (no init.py), so many top-level modules share a basename and collapse to a single FQN: e.g. handler.py ×33, scheduler.py ×19, token_manager.py ×13, plus per-integration *_api.py duplicated. That makes a class such as token_manager.TokenManager ambiguous across ~13 project-level definitions. We believe a function parameter annotated with one of these ambiguous types drives flattenAmbiguousSymbols / copyWithoutUsages into a combinatorial expansion that exhausts the heap.

Minimal repro hypothesis (happy to build and attach a tiny repo): two package-less modules with the same basename, in different directories, each defining a class of the same name; a third module with a function whose parameter is annotated with that class; no init.py anywhere.

Potential workaround:

None found that lets analysis complete. Tried: -Xmx5g (max safe on a 7 GB runner — still OOMs), and excluding some of the duplicate modules from analysis (didn’t resolve). The only durable fix we can see on our side is to disambiguate the module FQNs (make each lambda a proper package), which is a large structural change. Ideally the analyzer would bound/memoize flattenAmbiguousSymbols for highly-ambiguous or cyclic symbol graphs. Is there a fix in a newer analyzer version, or a config to cap parameter-type resolution against ambiguous symbols?

EDIT: Fixed this by adding pyproject.toml