Contact cleanup reliability when changing physics engines in Gazebo 11

Short answer

No. Gazebo 11 does not document or guarantee complete release of all engine-level contact allocations when a model is removed, and the guarantee cannot be extended uniformly across ODE, Bullet, and DART. What Gazebo itself owns (its per-step contact caches, such as the ContactManager) is cleared each physics update and torn down with the model; what the physics engine owns internally is engine-dependent and outside Gazebo's contract.

What is confirmed vs. likely

Confirmed behavior: Gazebo forwards collision detection to the selected physics engine, so contact objects are created and owned inside the engine's collision detector. Gazebo clears its own contact bookkeeping every step, and deleting a model through the world/model interface destroys that model's collision entities and their associated contact managers. That is the primary cleanup path, independent of whether the model was spawned via the GUI, gz model --spawn-file, or a factory message.

Likely explanation per engine:

• ODE (default): Contact joints are created per collision step into a joint group that is cleared at the end of the step, so transient contacts do not accumulate while the model exists. Memory growth reported with ODE typically traces to long-lived collision spaces or residual objects after entity deletion, not to leaked contact points from short-lived collisions.
• Bullet: Uses persistent contact manifolds and its own pair management, so the ownership model differs fundamentally from ODE. Bullet support in Gazebo 11 is less mature and should be treated as experimental.
• DART: Computes contacts per step, but the Gazebo 11 DART backend is also less exercised than ODE. Cleanup-on-removal is not uniformly tested across engines.

Because of these different ownership models, an ODE result must not be generalized to Bullet or DART.

Classic vs. new Gazebo

Gazebo Classic 11 and the new Gazebo (formerly Ignition) line use entirely separate physics abstraction layers: the legacy gazebo::physics engine classes versus the gz-physics plugin architecture (DART by default in gz-sim). Cleanup behavior for a given engine is therefore not guaranteed to be consistent between the two product lines, and Classic findings do not transfer. Note also that Gazebo Classic 11 reached end of life in January 2025, so any residual leak you find is unlikely to be fixed upstream.

How to verify for your case

Since no cross-engine guarantee exists, measure it directly:

1. Script a loop that spawns a model, forces a brief collision, then deletes it through the world/model interface, repeated several hundred times.
2. Profile the server with a heap profiler, e.g. valgrind --tool=massif gzserver ... or heaptrack, and check whether heap usage returns to baseline after each removal cycle.
3. Repeat with the physics engine set to ode, bullet, and dart and compare growth slopes.
4. If growth appears, test whether it scales with contact count (leaked contacts) or with model count (leaked collision entities) to localize ownership.

One caveat: behavior may differ between Gazebo 11.x patch releases, so record your exact version (gzserver --version) alongside any measurement before drawing conclusions.