1. 10 Feb, 2020 1 commit
    • Aleksy Barcz's avatar
      workaround for unitialized memory read on import set · 936b3617
      Aleksy Barcz authored
      + if we import a set in draw3 (from .xsd file), defcfg won't set _configId in imported params, leaving it uninitialized and leading to strange errors
      + initialize _configId to invalid value, so at worst it will fail in a more comprehensible way
      + we cannot throw from GetConfigId because of the "Caught unhandled unknown exception; terminating" wx behaviour which hides the place in code from which an exception is thrown. Overriding OnUnhandledException and OnExceptionInMainLoop in szapp (and e.g. calling abort, terminate from there) has no effect.
      + introduced a workaround in a completely different part of code than importing set, as the bug in importing set would be hard to find
      936b3617
  2. 04 Feb, 2020 2 commits
    • Aleksy Barcz's avatar
      launch query executor after all configs are loaded · 3f3418cc
      Aleksy Barcz authored
      + launch query executor as the last step of OnInit
      + this fixes a segfault when QueryExecutor tries to SetProberAddress while OnInit didn't finish loading configurations
      + probably this worked previously only because configurations loaded fast enough
      3f3418cc
    • Aleksy Barcz's avatar
      deadlock in UDIC/UDIM fix continuation · ec8d2a29
      Aleksy Barcz authored
      + follow-up of "fixed deadlock in defined initialization"
      + previous fix fixed the deadlock in one case, but not in the general case, as unfortunately there are other call-traces that lead to the deadlock
      + this fixes a sequence, where thread 1 calls UDIM::AddUserDef (acquires mutex), which calls UDIC::AddUserDef (acquires m_lock); while thread 2 calls PCIC::GetConfig (acquires m_lock), which calls UDIC::AddConfig, which calls UDIM::PopConfig (acquires mutex)
      + the general design flaw is that UDIM can call UDIC and vice versa. This is wrong and especially bug-prone when using locks.
      + this fix should fix the general case. The design flaw remains to be fixed, but now whenever UDIM calls UDIC, it does so without holding mutex (fixed both places in code where I found such a situation). So both locks are held only on the path from UDIC to UDIM and not vice versa.
      ec8d2a29
  3. 28 Jan, 2020 3 commits
  4. 22 Jan, 2020 2 commits
    • Aleksy Barcz's avatar
      libparnt: lock everything · 9ce9aa92
      Aleksy Barcz authored
      + there is a lock introduced in "Add global parser synchronous access mutex", but still draw3 segfaults on init
      + segfaults are not reproducible using valgrind, and happen in AddPar, where curr points to a badly initialized structure
      + altogether this looks very much like a multithreading issue
      + so introduce a recursive_lock, locking every single function in libparnt
      + this is extremely ugly, but it works and it doesn't slow down program start remarkably
      + a proper fix would be removing all the libparnt code and writing a new, simple, parser for szarp.cfg
      9ce9aa92
    • Aleksy Barcz's avatar
      Removed signal handlers from draw3 · 2275b41d
      Aleksy Barcz authored
      + caused deadlocks on program exit, as functions called from signal handler were not async-signal-safe (see: man signal-safety). Amongst others, malloc and pthread_join are not safe.
      + OS will cleanup our threads and db queue anyway
      + saving defined user params on exit is no longer necessary as we save them on every edit action
      + because of all the above, we can safely leave signal handling and cleanup to standard OS behavior on Linux
      2275b41d
  5. 28 Dec, 2019 1 commit
  6. 15 Dec, 2019 2 commits
  7. 11 Dec, 2019 1 commit
    • Aleksy Barcz's avatar
      ddedmn fixed build · 9a3c543f
      Aleksy Barcz authored
      + removed ifdef, which was hiding the fact that ddedmn wasn't properly built
      + fixed linking libraries
      9a3c543f
  8. 01 Dec, 2019 2 commits
  9. 19 Nov, 2019 2 commits
  10. 15 Nov, 2019 1 commit
  11. 13 Nov, 2019 1 commit
  12. 12 Nov, 2019 2 commits
  13. 01 Nov, 2019 3 commits
  14. 18 Oct, 2019 1 commit
  15. 05 Sep, 2019 1 commit
  16. 02 Sep, 2019 1 commit
  17. 30 Jul, 2019 3 commits
  18. 25 Jul, 2019 1 commit
  19. 22 Jul, 2019 1 commit
  20. 19 Jul, 2019 2 commits
  21. 18 Jul, 2019 2 commits
  22. 17 Jul, 2019 2 commits
  23. 15 Jul, 2019 1 commit
  24. 12 Jul, 2019 2 commits