
ID	0043
Class	BUG
Severity	3
Status	blocked
Models	MooringCable
Found	2026-09-25, review of the MARE-0029 smoke tests
Decision needed	Deferred by the owner (interview 2026-09-25): diagnose the `NumElements="10"` crash later. When it is picked up, choose how chain element counts are formed (options below).

Evidence

tests/in/MooringCable/MooringCable_in.xml with NumElements="10" instead of "30" (element length 150/10 = 15 m, with 15 m top and bottom chains, so one chain element each by MooringCable.cpp:31-35), run with FhSim, exits with SIGSEGV (139); with 30 elements it passes. Under gdb:

#0  CoRiBoDynamics::CollisionManager::GeometricObject::Update() ()
#1  CoRiBoDynamics::TrawlCableCollisionManager::ComputeConstraints(double, double const*) ()
#2  CoRiBoDynamics::CoreBoundThreadPool::WorkUnit::ThreadLoop() ()

The cause is not diagnosed. Candidates: the static_cast<int> truncation of TopChainLength / m_ElementLength at MooringCable.cpp:32-35 (a 0-element chain would make TopChainProperties.elements.back() at :400 undefined), or the collision segments of one-element chains.

Interview analysis (2026-09-25)

The truncation at MooringCable.cpp:31-35 gives exactly one element per chain for the failing input (15 m chains, 15 m elements), so it is probably not the cause of this crash. Other inputs do get 0-element chains, which made TopChainProperties.elements.back() (MooringCable.cpp:413, :406 at the time of the interview) undefined.
The second suspect is the collision manager's segment indexing (TrawlCableConstraintSets.cpp:224-251, the loop between and after the mooring segments that MARE-0062 extended); one-element segments have start == end.
Options for the element counts: A reject a chain whose length does not give a whole number of elements; B round to the nearest count, with a minimum of 1 (or 2), and warn; C give each segment its own element length. The mid rope needs a minimum too (MARE-0050 assumes one).
Recommendation from the interview: yes to diagnosing the crash; option B; a minimum of at least one element per segment.

Zero-element segments (fixed separately)

The reviewer confirmed a second, independent crash: with tests/in/MooringCable/MooringCable_in.xml and TopChainLength="4" (element length 5 m), m_TopChainNum becomes 0, and FinalSetup's AddMainCableSegment dereferences elements.begin() of the empty list (TrawlCableConstraintSets.cpp:174), a SIGSEGV. A segment of fewer than one element is invalid input and the check does not change any valid result, so it was fixed at once: see "Partial fix" below. This issue stays open for the NumElements="10" crash.

Effect

Some coarse mooring discretisations crash instead of running or reporting a bad parameter.

Possible fix

To be found. If it is a zero-element segment, round the element counts and reject fewer than one element per segment with an error.

Test that would prove it

A smoke fixture with NumElements="10", run like SimObject.MooringCable_Smoke.

Risk

Unknown until diagnosed.

Partial fix (<tt>1f61806</tt>, 2026-09-25)

MooringCable::ValidateSegmentElementCounts reports a setup error when the top chain, the bottom chain or the mid rope gets fewer than one element: "TopChainLength must be at least one element length", the same for BottomChainLength, and "The mid rope must have at least one element". New test SimObject.MooringCable_EmptySegment with the fixtures MooringCable_ShortTopChain (TopChainLength="4"), MooringCable_ShortBottomChain (BottomChainLength="4") and MooringCable_NoMidRope (two 75 m chains on the 150 m line). RED: all three exited with SIGSEGV (139); gdb puts the first in TrawlCableCollisionManager::AddMainCableSegment called from MooringCable::FinalSetup. GREEN: each fails at setup with its message. Valid inputs are unchanged.

Deferred by owner: the NumElements="10" crash in GeometricObject::Update is not diagnosed and stays open (status blocked), with the element-count options above.