pgmodeler-cli --fix-model segfaults (exit 139) after writing the fixed file, in minimal environments

[Gheop]

Summary

pgmodeler-cli --fix-model writes the repaired model file completely and
prints Fixed model file: ..., then segfaults (exit 139) while the
DatabaseModel is destroyed at program shutdown. The work is done; only the
exit code is wrong. This breaks any automation that (reasonably) trusts the
CLI's exit code, which is common in containers and CI.

The crash is a use-after-free during object teardown and is memory-layout
dependent: it reproduces reliably in a minimal environment and disappears as
soon as any extra environment variable is added. This makes it systematic in
small-environment contexts (containers) and easy to miss on a normal desktop.

Environment

• pgModeler 1.2.2-2.fc44 (Fedora 44 package)
• Qt 6.11.1
• x86_64, headless (QT_QPA_PLATFORM=offscreen)

Steps to reproduce

Using the sample model shipped with the package, in a deliberately minimal
environment:

env -i HOME="$HOME" PATH=/usr/bin QT_QPA_PLATFORM=offscreen \
  pgmodeler-cli --fix-model \
  --input /usr/share/pgmodeler/samples/pagila.dbm \
  --output /tmp/fixed.dbm
echo "exit=$?"

Result:

Fixed model file: /tmp/fixed.dbm
exit=139

/tmp/fixed.dbm is present, complete (~300 KB) and valid — re-importing or
exporting it works fine.

Adding any environment variable masks the crash (exit 0), e.g.:

env -i HOME="$HOME" PATH=/usr/bin QT_QPA_PLATFORM=offscreen \
  LD_LIBRARY_PATH=/does/not/exist \
  pgmodeler-cli --fix-model --input /usr/share/pgmodeler/samples/pagila.dbm \
  --output /tmp/fixed.dbm
# exit=0

This env-size sensitivity is the classic signature of a heap use-after-free
whose outcome depends on allocation layout.

Expected vs actual

• Expected: exit 0 after a successful fix.
• Actual: the file is written and success is printed, but the process
  exits with SIGSEGV (139).

Backtrace

Captured with gdb in the same minimal environment:

Program received signal SIGSEGV, Segmentation fault.
#0  BaseObject::unsetDependency(BaseObject*)      libcore.so.1
#1  BaseObject::clearReferences()                 libcore.so.1
#2  DatabaseModel::__removeObject(BaseObject*, int, bool)  libcore.so.1
#3  DatabaseModel::destroyObjects()               libcore.so.1
#4  DatabaseModel::~DatabaseModel()               libcore.so.1
#5  DatabaseModel::~DatabaseModel()               libcore.so.1
#6  PgModelerCliApp::~PgModelerCliApp()           libcli.so.1
#7  main

The crash is in dependency cleanup (BaseObject::unsetDependency /
clearReferences) reached from DatabaseModel::destroyObjects() during
~DatabaseModel() — i.e. teardown after the fixed file has already been
written. It looks like an object is referencing a dependency that has already
been freed during destroyObjects().

Scope

• Only --fix-model is affected here. In the same minimal environment,
  --export-to-file on the fixed model exits 0 and produces correct SQL
  (22 CREATE TABLE for pagila), so the teardown path taken by --fix-model
  is the one at fault.
• Observed with the bundled samples/pagila.dbm (an older-format model that
  --fix-model upgrades). Any model whose fix touches this dependency path is
  likely affected.

Impact and workaround

For callers that convert .dbm files in scripts/containers, the non-zero exit
code falsely signals failure even though the fixed file is correct. Our
workaround is to ignore --fix-model's exit code and instead check that the
output file exists and is non-empty before proceeding; a subsequent
--export-to-file (which does return correct codes) then validates the
result. It would be much cleaner if the CLI returned 0 on a successful fix.

[rkhaotix]

This bug is already fixed. Try 1.2.3 or 2.0.0-beta.

[Gheop]

Thanks! I checked, and unfortunately the use-after-free is still present in 1.2.3: the fix only exists in develop / 2.0.0-beta.

I ran the reproducer from the report under valgrind (--undef-value-errors=no --error-limit=no) against three builds, on Fedora 44 / Qt 6.11.1:

Build	use-after-free reads reported by valgrind
1.2.2 (Fedora package + debuginfo)	26
v1.2.3 (built from the tag, debug)	24
develop @ 83c7630 (debug)	0

The invalid reads all match the crash backtrace above: during DatabaseModel::destroyObjects(), Table::~Table() → PhysicalTable::destroyObjects() deletes table children (e.g. Constraint) that other objects still hold in their deps/refs vectors, and BaseObject::clearReferences() / unsetDependency() later dereferences the freed objects. Whether that actually segfaults depends on heap layout, which is why the crash only shows up with a stripped-down environment.

Representative trace from the v1.2.3 build:

Invalid read of size 8
   at std::vector<BaseObject*>::end() (stl_vector.h:1009)
   by BaseObject::unsetDependency(BaseObject*) (baseobject.cpp:1573)
   by BaseObject::clearReferences() (baseobject.cpp:1601)
   by BaseObject::clearAllDepsRefs() (baseobject.cpp:1609)
   by DatabaseModel::__removeObject(BaseObject*, int, bool) (databasemodel.cpp:557)
   by DatabaseModel::destroyObjects() (databasemodel.cpp:863)
   by DatabaseModel::~DatabaseModel() (databasemodel.cpp:291)
 Address 0x1e57cf30 is 48 bytes inside a block of size 928 free'd
   at operator delete(void*, unsigned long)
   by Constraint::~Constraint() (constraint.cpp:61)
   by PhysicalTable::destroyObjects() (physicaltable.cpp:56)
   by Table::~Table() (table.cpp:37)
   by DatabaseModel::destroyObjects() (databasemodel.cpp:869)
   by DatabaseModel::~DatabaseModel() (databasemodel.cpp:291)

The fix seems to be 0883e68 ("fix crash after diff and closing app"), which clears every object's deps/refs in a first pass before any deletion happens. It landed in develop on 2026-03-13, i.e. after v1.2.3 was tagged (2026-02-06), so only 2.0.0-beta ships it. With that commit, valgrind reports zero use-after-free on the same reproducer.

Since distros currently package 1.2.x (Fedora 44 ships 1.2.2), would you consider a 1.2.4 point release with that commit backported? I verified it cherry-picks cleanly onto v1.2.3 (18 lines, 2 files). Happy to open the backport PR if that helps.

[rkhaotix]

I'm heavily focused on 2.0.0 development, which is under beta1 (to be released soon). You can do the PR but I can't guarantee that this fix will be released anytime soon.