Skip to content

Running Linux tests on Windows

Jump to bottom
eoudejans edited this page Jun 16, 2026 · 2 revisions

Running Linux (.l) tests on Windows

The regression harness (batch/full.py) can run the Linux build of GeoDMS from a Windows machine by driving it through WSL2. This page collects what you need to know to make -version <ver>.l runs work and what the common failure modes are.

Related: Running tests with Claude (automation gotchas) · Test references and report generation

TL;DR

# from batch\
python full.py -version 20.1.0.l                                  # whole suite on the linux build
python full.py -version 20.1.0.l -tests t100_network,t300_xml     # a subset
python full.py -version 20.1.0.l -tests t1630,t1640,t1642 -linux-gui  # GUI tests (see caveat)

Always launch long runs detached (see Running tests with Claude).

How it works

-version 20.1.0.l (any version ending in .l) makes full.py:

  1. Resolve the binary to the WSL-installed build at /opt/ObjectVision/GeoDms<ver>.l/ (GeoDmsRun + GeoDmsGuiQt). Not C:\dev\GeoDMS\build\... — that is the local build directory, used only by -version local-linux-release.
  2. Set GeoDmsRunPrefix = "wsl --" and GeoDmsLocalFlavor = "linux-release", so every command runs as wsl -- /opt/.../GeoDmsRun ....
  3. Translate every path in the command line and env vars from Windows form to WSL form: C:/... → /mnt/c/..., D:/... → /mnt/d/.... It also prepends a WSLENV=... list so wsl.exe forwards the (now POSIX-shaped) env vars into the distro.
  4. Write TempDir/results_folder.txt with the WSL-translated result-folder path, because the cfg reads it back via %LocalDataDir%/.../results_folder.txt and the Linux binary needs a /mnt/c/... path there.

The build is installed from the .deb (in ~/Downloads/GeoDMS-<ver>/); shared libs are registered via ldconfig (/etc/ld.so.conf.d/geodms.conf) plus unixodbc. Distro: Ubuntu 26.04 (WSL2).

WSL prerequisites (do this once after every Windows reboot)

WSL2's swap must be re-allocated after a Windows reboot, or large tests OOM/wedge the VM:

wsl --shutdown
wsl -d Ubuntu -- free -h      # boots it fresh; confirm Swap shows ~304Gi

The swap file lives on a fast disk (D:\WSL\swap.vhdx, configured in .wslconfig). The ~47 GiB Mem you see in free -h is the WSL VM allocation; the host has more.

Sanity-check the build links before a run:

wsl -d Ubuntu -- bash -lc 'ldd /opt/ObjectVision/GeoDms20.1.0.l/GeoDmsRun | grep -i "not found"'   # empty = OK

Per-test wsl --shutdown (anti-cascade)

The profiler runs wsl --shutdown after each .l test. This is deliberate: if a test hangs and is killed, it can leave WSL in a state where the sampler reports "sampler produced no rows" for every following test (a cascade that looks like many failures but is one wedged VM). Shutting WSL down between tests gives each test a clean VM. It also adds a few seconds of boot overhead per test — that is expected.

Timeouts and drvfs slowness

  • Per-test caps live in profiler.py (TEST_TIMEOUTS), with LINUX_TIMEOUT_FACTOR = 2 because the /mnt/c filesystem (drvfs) is much slower than native ext4.
  • Heavy I/O to /mnt/c is slow and can fail outright: e.g. gdal ... TIFFAppendToStrip: Write error writing large TIFs (seen in t641 RSopen, which writes its BaseData to /mnt/c/LocalData/regression/...). The C: drive is not full — this is a drvfs large-write limitation. Candidate fix: point heavy intermediate output at a WSL-native path instead of /mnt/c. t641 on .l also simply takes hours via drvfs.

GUI tests on .l (GeoDmsGuiQt) — currently broken

t1630 / t1640 / t1642 drive GeoDmsGuiQt with a /T<dmsscript>. They are skipped by default on .l; pass -linux-gui to run them.

Status: they do not work on the current build, and this is a build/deployment issue, not config:

  • GeoDmsGuiQt 20.1.0.l was built against Qt 6.4 (its bundled platforms/ plugins report version 6.4.0), but Ubuntu 26.04 only offers Qt 6.10. ldd reporting "all libs OK" is misleading — linking ≠ running.
  • With the bundled 6.4 plugins: qt.qpa.plugin: Could not find the Qt platform plugin "xcb"/"wayland" → abort, no /L log.
  • Forcing the system 6.10 plugins (QT_QPA_PLATFORM_PLUGIN_PATH=/usr/lib/x86_64-linux-gnu/qt6/plugins/platforms) gets past that but then segfaults — even with -platform offscreen (headless). So the app itself crashes under Qt 6.10.

To make GUI tests work on .l, the build side must rebuild GeoDmsGuiQt against Qt 6.10, ship a self-contained Qt 6.4 runtime with it, or install Qt 6.4 on the target.

WSLg display is fine: DISPLAY=:0 and WAYLAND_DISPLAY=wayland-0 are set even in a non-login wsl -- context, and /tmp/.X11-unix/X0 + /mnt/wslg are present. So the blocker is the Qt version, not the display.

With -linux-gui set, a crashed GUI test now correctly reports gecrasht (geen log) in the report (see the false-pass detection in Test references and report generation) instead of a hollow "ok".

Preflight checklist

  • wsl --shutdown + wsl -d Ubuntu -- free -h shows ~304Gi swap (after a reboot)
  • ldd .../GeoDmsRun has no "not found"
  • launching detached (not as a child of your shell / automation session)
  • using disambiguated -tests names (t100_network, not t100; t2000_hestia, not t200)
  • for GUI: only with -linux-gui, and expect gecrasht until the Qt build is fixed

Troubleshooting

Symptom Likely cause Action
Every test "sampler produced no rows" WSL wedged by a previous hung test wsl --shutdown; the per-test shutdown should prevent this
OOM / VM dies on a big test (t2000) swap not allocated after reboot wsl --shutdown then free -h to boot fresh
TIFFAppendToStrip: Write error (t641) drvfs large-write to /mnt/c redirect heavy writes to a WSL-native path; expect long runtimes
GUI test gecrasht (geen log) Qt 6.4 build vs system Qt 6.10 build-side fix; not a config issue
Run dies mid-line, no error started as a child of the session launch detached (see Running tests with Claude)

Clone this wiki locally