[us-commits] [ehb54/ultrascan3] e99300: somo/grpy: report bad input and failed allocation ...

[emre brookes]

  Branch: refs/heads/ehb54-issue-1009-somo-review-fixes
  Home:   https://github.com/ehb54/ultrascan3
  Commit: e993002a13ba1a428967d55ca1f1d4f17d85997c
      https://github.com/ehb54/ultrascan3/commit/e993002a13ba1a428967d55ca1f1d4f17d85997c
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    M us_somo/develop/grpy/grpy_api.hpp
    M us_somo/develop/grpy/linalg.hpp

  Log Message:
  -----------
  somo/grpy: report bad input and failed allocation instead of aborting

Running GRPY in-process removed the isolation the subprocess gave it, but the
module still failed like standalone code.

linalg.hpp
- The in-core calloc return was unchecked, so a failed allocation was followed
  by tile accesses through a null pointer. These are exactly the sizes that
  fail: this allocation is the memory wall the tiling exists for.
- Out-of-core setup called std::abort() when the backing file could not be
  created, sized or mapped, so an unwritable or full directory killed SOMO and
  any unsaved work with it. Now closes and unlinks the partial file and throws,
  naming the path and the errno.
- Both raise the new la::Error. Also widen the tile row offset before the
  multiply (roff()): i * b was computed in int and only then converted to
  Eigen::Index, which is what CodeQL flags at the six middleRows() calls.

grpy_api.hpp
- read_native_file() accepted every failure silently: a missing file, a
  truncated file or a non-numeric field all produced zeros, which became N == 0
  or zero-radius beads and surfaced much later as a division by radius or a
  quietly meaningless result. It now validates the open, every scalar field,
  the declared bead count and each bead line, and rejects a non-finite
  coordinate or a radius that is not positive -- naming the file and line.

Reported-by: aaron-auc
(cherry picked from commit 1e489e741362fe17744b1b4c8dd70ab6688d94ca)


  Commit: e792f3dc8b2869ee86152a418da23c2d6e7399c6
      https://github.com/ehb54/ultrascan3/commit/e792f3dc8b2869ee86152a418da23c2d6e7399c6
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    M us_somo/develop/src/us_hydrodyn_grpy.cpp

  Log Message:
  -----------
  somo/grpy: add a failure boundary, and let Stop reach the solve

Two defects that both come from the move to an in-process solver.

A failure boundary. As a subprocess a GRPY failure was isolated -- the process
died, SOMO read a non-zero exit and carried on. In-process there is nothing
between a throw and the application: a failed allocation, an unreadable input
or a bad out-of-core path would terminate SOMO and lose the session. The parse
and the whole compute now run inside a try; the catch reports the error and
restores the interface exactly as the pre-flight memory guard does when it
refuses a model, and in gui_script mode fails properly to stderr with a
non-zero exit rather than reporting success. The body is left at its existing
indentation so the diff shows the boundary and nothing else.

Stop. sopt.should_stop was installed inside 'if ( sopt.enabled )', so it existed
only for a shell-reduced run. With shell reduction off -- the default, and now
the only configuration -- nothing was installed and Stop could not reach the
solve at all: the progress callback's 'if ( stopFlag ) return;' suppresses
repaints but does not end the computation, so a long model ran to completion
looking hung. Install it for every run.

This does not make Stop instant. A solve already running still finishes, since
the factor has no interior abort; with a ladder, Stop takes effect between rungs
and saves nearly all of what remained. Said plainly in the comment rather than
implied.

Reported-by: aaron-auc
(cherry picked from commit 876a76a1fd47c75e70def12fab87b0fff40f1dce)


  Commit: 9f4a2289b2bfe3abb412a4681fc795235555326e
      https://github.com/ehb54/ultrascan3/commit/9f4a2289b2bfe3abb412a4681fc795235555326e
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    M us_somo/develop/src/us_hydrodyn_other.cpp

  Log Message:
  -----------
  somo: don't let Close act during a running GRPY solve

The GRPY solve runs synchronously on the GUI thread and calls processEvents()
to keep the interface responsive, which also leaves Close live. Taking it would
hide the window, clear the temporary directories and ask the application to quit
while the solve was still running over those files -- SOMO appearing closed
while it went on computing.

closeEvent() now treats Close as a Stop request while grpy_running: it sets
stopFlag, says that the current model must finish first because the solve cannot
be interrupted part-way, and ignores the event. Closing again once it has
stopped behaves normally.

Reported-by: aaron-auc
(cherry picked from commit 5bf6554af39173167c0b78fb1307373d4329f15e)


  Commit: 6325fd38e1a75ebc8fedf76bb823483a0b458f2b
      https://github.com/ehb54/ultrascan3/commit/6325fd38e1a75ebc8fedf76bb823483a0b458f2b
  Author: ehb54 <brookes at uthscsa.edu>
  Date:   2026-08-17 (Mon, 17 Aug 2026)

  Changed paths:
    M us_somo/develop/grpy/grpy_core.hpp

  Log Message:
  -----------
  somo/grpy: record the GRPY provenance, copyright and citation

grpy_core.hpp describes itself as a faithful translation of GRPY.f but recorded
neither its author, nor its license, nor the paper to cite.  Add all three:
Copyright (C) 2017 Pawel Jan Zuk, GPLv3 per the GRPY.f header, and Zuk,
Cichocki & Szymczak, Biophys. J. 115:782-800 (2018).

The note deliberately stops short of asserting a licensing outcome.  The
original is GPLv3, UltraScan is LGPLv3, and a translation is a derivative work,
so compatibility is a project-level decision that a source header cannot settle.

Reported-by: aaron-auc


Compare: https://github.com/ehb54/ultrascan3/compare/e993002a13ba%5E...6325fd38e1a7

To unsubscribe from these emails, change your notification settings at https://github.com/ehb54/ultrascan3/settings/notifications