Pinch zoom can pass a non-positive scale to math.log, poisoning the camera with NaN

[bdog720]

What is the bug?

_getZoomForScale can be handed a non-positive scale, making math.log() return NaN/-Infinity, which then propagates into the camera via moveRaw unvalidated.

In map_interactive_viewer.dart, the pinch-zoom branch guards details.scale but passes details.scale + _scaleCorrector:

// L650-654
if (hasPinchZoom && details.scale > 0.0) {
  newZoom = _getZoomForScale(
    _mapZoomStart,
    details.scale + _scaleCorrector,   // <- the sum is never checked
  );

_scaleCorrector is set when the finger count changes mid-gesture (L617):

_scaleCorrector = 1.0 - _lastScale;

so it is negative whenever _lastScale > 1 (i.e. the user was zooming in when a finger was added/removed). The sum is then details.scale + 1.0 - _lastScale, which is <= 0 as soon as details.scale <= _lastScale - 1. Concretely: a finger lifts at _lastScale == 2.5 (_scaleCorrector == -1.5), the recognizer restarts the new gesture near details.scale == 1.0, and the sum is -0.5.

_getZoomForScale has no guard, and clampZoom cannot recover it because NaN.clamp() returns NaN in Dart:

// L1404-1408
double _getZoomForScale(double startZoom, double scale) {
  final resultZoom =
      scale == 1.0 ? startZoom : startZoom + math.log(scale) / math.ln2;
  return _camera.clampZoom(resultZoom);
}

log(negative) is NaN and log(0) is -Infinity, so newZoom becomes non-finite and is passed straight to controller.moveRaw(newCenter, newZoom, ...). _calculatePinchZoomAndMove also consumes that same zoomAfterPinchZoom, so the resulting center goes NaN too.

Once the camera holds a non-finite center/zoom, every layer that reads it breaks. The MapCamera constructor's assert(zoom.isFinite) only fires in debug builds, and it covers zoom but not center, so release builds store the poisoned camera silently.

I want to flag how this interacts with the recent NaN work, because I think it makes the bug easier to miss now rather than harder:

• fix: throw when LatLng is non-finite #2182 (in 8.3.0) added the Crs.checkLatLng throw. That surfaced this as a hard crash, which I believe is why Exception thrown when during rapid zooming #2214 reported "only happens starting with version 8.3, no problems with 8.2" — the NaN was likely already being produced, and 8.3.0 just made it fatal.
• revert: fix: throw when LatLng is non-finite #2218 reverted fix: throw when LatLng is non-finite #2182 for 8.3.1, and checkLatLng is now gone from master.

The revert removes the exception, but the arithmetic above still produces the NaN. So on 8.3.1+ the same gesture should yield a silently non-finite camera — a stuck/blank map rather than a stack trace. That matches the "Map is stuck" wording in #2199. I mention it only because a silent version of this is harder to diagnose than the crashing one, not to argue the revert was wrong.

Honest caveat on evidence: this is code-path analysis plus production telemetry, not a captured repro. I have Crashlytics reports from a released Android app on 8.3.0 showing LatLng(latitude:NaN, longitude:NaN) reaching Crs.checkLatLng from four different layers (MarkerClusterLayer.didUpdateWidget, MarkerLayer.build, TileLayer._onTileUpdateEvent, _buildMobileTransformStack) — the signature of an already-poisoned camera rather than one bad input. I ruled out my own call sites: every move/fitCamera in the app is validated and instrumented, and the rejection counter never fired once. The pinch path is the one route to the camera that bypasses application code, and the unguarded sum above is a real defect on master regardless of whether it is what my users hit.

How can we reproduce it?

I have not been able to reliably reproduce the gesture by hand — the window where details.scale + _scaleCorrector goes non-positive requires a finger count change while zoomed in, then a rapid continuation. #2214's "rapidly zooming in and out" with varying finger counts on Android is the closest description I have.

The arithmetic itself is directly demonstrable without gestures:

// _scaleCorrector == 1.0 - _lastScale, with _lastScale == 2.5
const scaleCorrector = 1.0 - 2.5;   // -1.5
const detailsScale = 1.0;           // recognizer restarts near 1.0
final scale = detailsScale + scaleCorrector;  // -0.5

// mirrors _getZoomForScale
final resultZoom = 13.0 + math.log(scale) / math.ln2;
print(resultZoom);              // NaN
print(resultZoom.clamp(0, 20)); // NaN — clampZoom cannot recover it

I am happy to try to build a proper WidgetTester gesture repro (driving ScaleUpdateDetails with a changing pointerCount) if that would be useful — I did not want to guess at the harness conventions before checking whether you would want the test at all.

Do you have a potential solution?

Guard the value actually passed to math.log, rather than details.scale alone. Either check the sum at the call site:

final scale = details.scale + _scaleCorrector;
if (hasPinchZoom && scale > 0.0) {
  newZoom = _getZoomForScale(_mapZoomStart, scale);

or make _getZoomForScale total, which also covers the other two call sites (L745 and L908):

double _getZoomForScale(double startZoom, double scale) {
  if (scale <= 0.0 || !scale.isFinite) return _camera.clampZoom(startZoom);
  final resultZoom =
      scale == 1.0 ? startZoom : startZoom + math.log(scale) / math.ln2;
  return _camera.clampZoom(resultZoom);
}

Separately, it may be worth rejecting non-finite values in moveRaw itself. With checkLatLng reverted there is now no runtime backstop between a non-finite gesture computation and a permanently poisoned camera, and a single bad frame persists until the app is restarted. Happy to open a PR for either or both if you have a preference on the approach.

[bdog720]

Correction to my own report — I got the 8.3.1 behaviour wrong above, and the reality is worse than what I wrote.

I claimed that with checkLatLng reverted, a non-finite camera would degrade silently into a stuck/blank map. That was inference from the changelog, and it is wrong. I've now actually run it against 8.3.1 in a widget test: projecting a NaN camera raises OutOfMemoryError, not a silent no-op.

controller.move(const LatLng(double.nan, double.nan), 13);
await tester.pump();
// >>> EXCEPTION TYPE: OutOfMemoryError
// >>> EXCEPTION: Out of Memory
// >>> CAMERA CENTER: LatLng(latitude:NaN, longitude:NaN)

(MarkerLayer with a single marker; MapCamera's assert(zoom.isFinite) is debug-only and doesn't cover center, so a NaN center passes move() either way.)

Which makes sense in hindsight — that's the unbounded allocation from #2178 that #2182's throw was added to prevent, resurfacing now that #2218 reverted the throw. So the sequence for a NaN camera is:

Version	Behaviour
8.2.x	unbounded allocation (#2178)
8.3.0	Exception: LatLng is not finite (#2182)
8.3.1	throw reverted (#2218) → back to OutOfMemoryError

I don't think this argues against the revert — #2199 makes it clear the throw was firing on legitimate interactions and that was worse in practice. But it does mean 8.3.1 has no backstop between a non-finite gesture computation and an OOM, and an OOM is considerably harder to trace back to a gesture than a named exception was. That raises the stakes on the unguarded details.scale + _scaleCorrector in the original report, so I wanted the record straight rather than leave a wrong claim sitting in the issue.

#2213 covers NaN coordinates on Markers specifically; the camera path appears to be separate.

Offer from the original report stands — happy to open a PR guarding _getZoomForScale, and/or rejecting non-finite values in moveRaw as a general backstop, if you have a preference on approach.

[JaffaKetchup]

Thanks for making this bug report. Please don't respond to this comment with AI.

First thing first, can you please check whether your issue is fixed on the actual master (maybe by #2220?). Also please read #2219 and see if your issue is related to that.

Honest caveat on evidence: this is code-path analysis plus production telemetry, not a captured repro. [...] real defect on master regardless of whether it is what my users hit. [...] I have not been able to reliably reproduce the gesture by hand.

So I think what this means is that your AI has done static analysis to determine these issues based on a crash report from Crashyltics? Could you share that trace log please?

The solution you've presented is adding guards or ignoring the issue. If there is an issue, I don't want to merge another AI generated PR which just covers it up. That's how I created this mess, by not just sticking to only merging PRs which solve root causes. checkLatLng was a bad idea and I should not have merged it, which is why I reverted it.

(MarkerClusterLayer.didUpdateWidget is not an FM core component so it is irrelevant).

#2199 (comment) backs up your theory, but I would like a clear trace from somewhere.

I claimed that with checkLatLng reverted, a non-finite camera would degrade silently into a stuck/blank map. That was inference from the changelog, and it is wrong.

Did you infer that, or did the AI infer that? v8.3.1 did not try to fix any additional issues around NaNs except specifically for Markers.

I've now actually run it against 8.3.1 in a widget test: projecting a NaN camera raises OutOfMemoryError, not a silent no-op.

controller.move(const LatLng(double.nan, double.nan), 13);
await tester.pump();

It's the marker layer going into an infinite loop as mentioned in #2178 (comment).

So here's where I'm at - yes, passing in NaNs with a marker layer causes an OOM. So, the resolution should consist of two parts made together:

• add protection to the infinite loops in the MarkerLayer (treating it as an independent component that should not cause OOMs ideally even when given bad inputs by the core) - ideally we'd also reuse workAcrossWorlds but more of my poor historical decision making has come back to bite me here so that needs some unpacking from being tied into a mixin
• fix whatever, if anything, is causing NaNs to be generated internally (an assertion is not appropriate here, only a fix for the root cause is)

If it's proven impossible to generate through actual gestures then I would consider the second part redundant. However, #2199 (comment) suggests that it is unfortunately possible.

[MacBuchi]

Field data and a measured blast radius for this, from a small production app (flutter_map 8.3.1, Android + web):

This fires often in the wild. Our error reporting caught Unsupported operation: Infinity or NaN toInt 61 times in a single week across a small user base, all with top frame _floor (package:flutter_map/src/layer/tile_layer/tile_range.dart) — i.e. a non-finite camera reaching the tile-range math. Symptom for users: grey areas until the next gesture repairs the camera.

The tile layer exception is the harmless half. With a non-finite camera, MarkerLayer's world-replication loops (for (double shift = worldWidth;; shift += worldWidth) in marker_layer.dart) never terminate: the culling test is Rect.overlaps, and IEEE comparisons with NaN make every overlap check pass, so break is never reached. We reproduced this twice on a Pixel 7 Pro with the VM service attached and measured ~150 MB/s of Positioned allocations, heap 134 MB → 3.8 GB in 24 s, main thread stuck assisting the GC (dart::MarkingVisitor::ProcessOldMarkingStack in the ANR dump), ending in an Android ANR ("Input dispatching timed out") or an OOM when the marker list's backing array tries to double past 256 MB. Related: #2178 covered a NaN in the marker's own LatLng; the camera path re-opens the same loop for perfectly finite markers.

Note MapCamera's constructor asserts zoom.isFinite — so debug builds crash early, while release builds (asserts stripped) run straight into the storm. That may be why this survives testing.

App-side workaround that stopped both symptoms for us, in case it helps others until the sources are fixed — every movement (gestures included) passes through MapOptions.cameraConstraint, and returning null from constrain() makes the movement a no-op:

class FiniteCameraConstraint extends CameraConstraint {
  const FiniteCameraConstraint();

  @override
  MapCamera? constrain(MapCamera camera) =>
      camera.zoom.isFinite &&
          camera.center.latitude.isFinite &&
          camera.center.longitude.isFinite &&
          camera.rotation.isFinite
      ? camera
      : null;
}

Perhaps worth considering upstream: validate in moveRaw (the release-mode counterpart of the existing debug assert), and/or make the marker world-replication loop break on non-finite positions.

[JaffaKetchup]

@MacBuchi

Our error reporting caught Unsupported operation: Infinity or NaN toInt 61 times in a single week across a small user base, all with top frame _floor (package:flutter_map/src/layer/tile_layer/tile_range.dart)...

This sounds like #2221, a separate issue from this which has been reported many times and is fixed on master right now. Please see #2227 (comment) to use the fix.

I think (or rather, as far as I'm aware) these are separate issues and should not be confused.

The tile layer exception is the harmless half. With a non-finite camera, MarkerLayer's world-replication loops [...]
and/or make the marker world-replication loop break on non-finite positions. [...]

This is just rehashing exactly what I said in my comment above.

App-side workaround [...]

This could be useful for readers, thanks for including this :) Although note that as said, it's just covering up root issue and so should ONLY be used as a workaround. Note also that it may be fixed on master if it's the issue I mentioned above you're bumping into rather than this one.