Worker thread reaches GetOrCreateDataController on late-bound (:=='') domain attributes — MG_CHECK fires at DataController.cpp:351

[MaartenHilferink]

Summary

When a worker thread evaluates a domain attribute whose expression is a late-bound string-constructed expression (using the := = template syntax), the engine reaches GetOrCreateDataController and the assertion at DataController.cpp:351 fires:

Check Failed Error: IsMainThread() || !mayCreate
C:\dev\GeoDMS_2026\tic\dll\src\DataController.cpp(351):
This seems to be a GeoDms internal error

In one of our regression runs (t720, 2BURP project) this fires 152 times, all from worker thread 33, on dynamically-constructed domain expressions.

The relaxation in commit 766848c9 (#361 fixed by replacing UnifyDomain()->GetOrCreateDC() -> MakeResult() by UnifyDomain()->GetExistingDC() -> MakeResult()) explicitly notes it as incomplete:

TODO: prevent UnifyXXX() to be called from WorkerThreads.

This issue is the realization of that TODO — there is at least one other code path that still routes through GetOrCreateDataController from a worker thread.

Repro

Run python full.py -version local (cmake-Release) or local-msbuild-release against the in-tree 2BURP regression test:

F:\SourceData\RegressionTests\prj_snapshots\2BURP\cfg\main\Analysis\Future.dms

Lines 10-18 build several _domain attributes via := '...' (late-bound string templates substituting ModelParameters/StartYear):

attribute<BuiltUpKm2>        BuiltUp_Residential_Area_domain (domain) := ='SourceData/BuiltUp/Residential/'+ModelParameters/StartYear+'[km2] / 1[km2] * 1[BuiltUpKm2]';
attribute<Person>            Population_domain               (domain) := ='SourceData/Population/PerYear/'+ModelParameters/StartYear+'[Person]';
attribute<Person_BuiltUpKm2> Population_inRes_Density_domain (domain) := Population_domain / BuiltUp_Residential_Area_domain;

The first two reach the assertion when evaluated by worker thread 33.

First error log lines

2026-05-08 11:31:52[33][[/Analysis/Future/InitialState/Impl/Population_domain]] Check Failed Error: IsMainThread() || !mayCreate
2026-05-08 11:31:52[33]C:\dev\GeoDMS_2026\tic\dll\src\DataController.cpp(351):
2026-05-08 11:31:52[33]This seems to be a GeoDms internal error...

A preceding line shows a tokenizer case-mix warning that hints at a substitution path being triggered:

2026-05-08 11:31:52[1]Depreciated mix-up of cases, tokenized 'Region_rel' as token 4754 and then seen 'region_rel' [[/Analysis/Future/InitialState/Impl]]

Likely culprits — to grep

The function only has two callers in the public API:

DataControllerRef GetOrCreateDataController(LispPtr keyExpr) { return GetDataControllerImpl(keyExpr, /*mayCreate=*/true); }
DataControllerRef GetExistingDataController(LispPtr keyExpr) { return GetDataControllerImpl(keyExpr, /*mayCreate=*/false); }

Anywhere a worker-thread codepath can reach GetOrCreateDataController(...) is a candidate. Particularly:

• tic/dll/src/AbstrCalculator.cpp:170,171,480,948,1058,1381 — substitution / meta-info paths
• tic/dll/src/AbstrUnit.cpp:292
• tic/dll/src/MoreDataControllers.cpp:162
• tic/dll/src/TreeItem.cpp:1092,2350,2419,2429,2452

Environment

• Branch: refactor_linux_gui @ 3f13e1e5 and prior parents
• Windows 11 Pro 26200; reproduces in cmake-Release and msbuild-Release
• /S1 /S2 /S3 multitasking flags

Priority hint

The same engine path is exercised by any cfg that builds domains via := ='...' string templates with metric casts. Likely impacts more tests than just t720 once we enable parallel evaluation more broadly.

[MaartenHilferink]

Update — this is cmake-build-specific, msbuild-Release does NOT reproduce.

Re-running t720 on the same machine, both flavors, side-by-side in the same report:

Column	Build	t720 status
20.0.0.c	cmake-Release (vcpkg toolchain)	**1 — `Check Failed Error: IsMainThread()
20.0.0.m	msbuild-Release (MSVC project)	OK — clean run, status_code=0, completes in 387s

So GetOrCreateDataController is reachable from a worker thread only in the cmake build. Likely candidates:

• Different STL / runtime — vcpkg's MSVC STL may have different std::mutex/std::thread semantics or thread-pool scheduling, exposing a latent race.
• Different optimization — cmake's /O2 may inline/reorder differently, changing which code paths a worker thread reaches.
• Different boost/Qt — if the worker-spawning library is supplied by vcpkg in the cmake build but by msbuild's vendored copy elsewhere, threading behaviour differs.

Both binaries were built from the same source tree (refactor_linux_gui at the same commit); only the build system differs. Worth diffing the imported-DLL lists between bin/Release/x64/GeoDmsRun.exe (msbuild) and build/windows-x64-release/bin/GeoDmsRun.exe (cmake).

The TODO from 766848c9 ("prevent UnifyXXX() to be called from WorkerThreads") still holds as the right structural fix, but the cmake-only manifestation hints at a more concrete starting point: which worker-spawning code is compiled differently between the two pipelines.

[MaartenHilferink]

IsMainThread() → IsMetaThread() sweep landed (commit 0165494c)

The right model for this assertion (and ~50 sibling sites) turned out to be the meta-thread baton: IsMainThread() is true only on the literal main thread, but the metadata pipeline can hand the baton to a worker thread (via SetMetaThreadID, e.g. inside TreeItem::UpdateMetaInfo to dodge stack overflow). Asserts/gates whose intent is "this code is the one currently holding the metadata baton" must therefore use IsMetaThread(), not IsMainThread().

Specific call sites that fired in the wild

The original MG_CHECK(IsMainThread() || !mayCreate) at DataController.cpp:351 was firing 152× on worker thread 33 in the t720/2BURP run. Two adjacent assertions had the same bug for the same reason:

• tic/dll/src/AbstrCalculator.cpp:650 — assert(IsMainThread()) in VisitSuppliers.
• sym/dll/src/Lispeval.cpp:557 — assert(IsMainThread()) in ApplyTopEnv.

All three converted to IsMetaThread() and the t720 worker-thread assertion failures stopped.

Sweep

Once those three were fixed, I swept the codebase for the same pattern. Final tally: 50 sites in 26 files flipped from IsMainThread() → IsMetaThread(), covering rtc/, tic/, stx/, sym/, clc/, stg/. Excluded:

• shv/, qtgui/ — Qt rendering / UI thread code, where IsMainThread() is the correct distinction (the Qt event loop runs on the literal main thread).
• rtc MainThread.cpp/.h — the implementation of IsMainThread() itself.

Surveyed but kept as-is in shv/qtgui (each one was checked individually):

• DataView painting, Qt-message dispatch, capture/release-mouse paths, QDmsViewArea::keyPressEvent → these are literally on the main thread by Qt design and IsMainThread() is the right semantic.

How to extend the heuristic for future contributors

If you're adding an assert(IsMainThread()) or MG_CHECK(IsMainThread()...), ask:

• "Could this fire on a worker thread that the metadata pipeline has handed the baton to?" If yes → use IsMetaThread().
• "Am I gating Qt-only / UI-only state (paint events, widget creation, GDI handles)?" If yes → keep IsMainThread().

The sweep also reveals that IsMainThread is a stronger guarantee than most metadata-pipeline code actually needs; future cleanups could likely remove a few of the remaining IsMainThread() checks entirely once their guarantees are reviewed.

cc: @MaartenHilferink

[MaartenHilferink]

Root cause and fix for the cmake-vs-msbuild divergence

The IsMainThread → IsMetaThread sweep (commit 0165494c) fixed the
assertion failures in this issue. Investigating the residual cmake-only
test failures (in particular t641_3_RSopen_Allocatie, which "completed"
on msbuild but produced no result on cmake) surfaced a second, deeper
problem with the same fingerprint.

Stack-reserve audit

Build	Main-thread stack reserve	Source
msbuild Release x64	64 MB (0x4000000)	DmsDef.props:55 <StackReserveSize>67108864</StackReserveSize> — applied via .vcxproj inheritance
cmake Release x64	1 MB (0x100000)	MSVC linker default; DmsDef.props is not inherited by the cmake build, no target_link_options(... PRIVATE "/STACK:…") anywhere in CMakeLists.txt
cmake Linux x64 (WSL)	8 MB (ulimit -s = 8388608)	glibc/kernel default

Worker threads inherit the EXE's PE-header stack on Windows, so the cmake build also gives std::async workers 64× less stack than the msbuild build.

Why this looked like the meta-thread baton bug

TreeItem::UpdateMetaInfo hands work to a worker thread when RemainingStackSpace() <= 327680 (= 320 KB). On the cmake 1 MB main-thread stack the threshold trips when only ~700 KB has been consumed; on the msbuild 64 MB stack it's effectively unreachable. The IsMainThread ↔ IsMetaThread divergences therefore manifested ~64× more readily on cmake, despite both builds sharing the same source.

Linux: the same threshold never fires

rtc/dll/src/utl/Environment.cpp line 1491 (Linux block) implemented RemainingStackSpace() as rl.rlim_cur / 2 — a fake constant (~4 MB on default 8 MB stack). The author's TODO comment said "rough approximation; for a more precise solution, use pthread_attr_getstack". The check 4 MB <= 320 KB is always false, so the meta-thread baton transfer never actually fires on Linux — deeply recursive cfg trees just overflow the main thread instead.

t641_3 verification — direct evidence

Same cfg, same machine, same date, only difference is the link-time stack reserve:

	cmake /STACK default (1 MB)	cmake /STACK:67108864 (64 MB)
Runtime to death/completion	7 seconds	853 seconds (~14 min)
Deepest path traversed	Y2050/Wonen_Provincie/Iter_**0**/StateNaAllocati… (log truncated mid-message)	Y2050/Wind_Provincie/Iter_**4**/StateNaAllocatie_Phase (full message, normal logging)
Peak CommitCharge	481 MB	261 GB
Exit cause	abrupt log cutoff with no error — classic SEH-stack-overflow signature inside DMS_SE_CALLBACK_BEGIN/END	clean operation; eventual error is a missing-file from workaround_issue_1101 running with the -tests t641_3 filter (i.e. the BaseData chain wasn't pre-populated by t641_1/t641_2) — unrelated to stack

Fixes (committed in 09c2b2d1)

run/exe/CMakeLists.txt and qtgui/exe/CMakeLists.txt:

target_link_options(GeoDmsRun PRIVATE "/STACK:67108864,8192")
target_link_options(GeoDmsGuiQt PRIVATE "/STACK:67108864,8192")

This brings the cmake Windows binaries to parity with the msbuild build's 64 MB stack reserve.

rtc/dll/src/utl/Environment.cpp Linux block: replace the constant rl.rlim_cur / 2 stub with a real per-thread measurement via pthread_getattr_np + pthread_attr_getstack, returning the byte distance from the current frame to the stack base. With this, the Linux build's meta-thread baton transfer actually fires when needed.

Proposed closure

The original assertion failures are addressed by 0165494c. The cmake-vs-msbuild divergence on heavy cfg trees is addressed by the stack-reserve link option in 09c2b2d1. The Linux mute-failure path is addressed by the real RemainingStackSpace() in the same commit. With these in place I think this issue can be closed once a full python full.py -version 20.0.0c run on the rebuilt cmake binary (with all 26 tests, prerequisites included) confirms the green state.

cc: @MaartenHilferink