TinyMUX 2.13.0.16 released

2 views
Skip to first unread message

Brazil

unread,
Aug 7, 2026, 9:41:08 AMAug 7
to tinymux
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Subject: [ANNOUNCE] TinyMUX 2.13.0.16 released

TinyMUX 2.13.0.16 is now available. This is a hardening release on the
2.13 line: twenty-five fixes, dominated by crash and denial-of-service
work and by the networking layer. Several of the crash fixes are
reachable by an ordinary player, so this is a recommended upgrade for
any game running 2.13. No configuration changes are required.

Changes since 2.13.0.15
- ------------------------------

- - Crash and denial-of-service fixes. The evaluator's recursion limit is
  now reachable before the stack runs out: mux_exec() kept an 8000-byte
  automatic buffer and recurses on two paths, so each nesting level cost
  roughly 17 KB of stack and the physical ceiling on a stock Linux
  server sat at 490 levels -- below the shipped recursion limit of 500.
  A player nesting u() about 491 deep crashed the server before the
  limit could fire. The buffer is now static, the frame drops from 8344
  to 328 bytes, and the ceiling rises to roughly 8500.

- - Three more player-reachable overruns are closed: @lock parser
  recursion is depth-bounded (a key with roughly 400 leading '!'
  characters overflowed the stack), @mail to a repeated mail alias no
  longer runs past a fixed 4000-entry recipient array, and the legacy
  getstring_noalloc() read path is bounded -- that one is not confined
  to old databases, because the EOF-marker read runs on every flatfile
  load.

- - Crash recovery. Uncaught C++ exceptions on the network and task paths
  no longer take the process down; barriers now wrap connection event
  dispatch, send_data, the task scheduler, and the accept branch of the
  main loop. SIGABRT takes the same panic-restart arm as SIGSEGV and
  friends rather than logging and exiting, and panic restart under GANL
  works again -- the signal path had never recorded listener descriptors
  for the restart database, and the core-dumping twin ran full exit()
  destructors that tore down sockets the parent still needed.

- - Networking. Thirteen GANL fixes across the epoll and select engines
  and the TLS transport: a connection-teardown re-entrancy, read events
  arriving on a closing connection, a failed epoll_wait() that spun the
  loop instead of being handled, an event fetch that could exceed the
  caller's array, an FD_SETSIZE clamp on select's descriptor loop, a
  not-found descriptor that was being closed, queued plaintext discarded
  when a TLS write had to be deferred, an uncapped OpenSSL read BIO, TLS
  descriptors carried across @restart and panic restart, and a
  dual-stack listener that silently bound IPv6-only now warning instead.

- - Engine debug logging is off unless GANL_DEBUG is defined at build
  time. This now covers the Windows engines (IOCP, wselect) and the
  Schannel transport as well as the POSIX ones; on a detached Windows
  service the output goes to the debugger rather than to a console that
  is not there.

- - Windows. The EXE stack reserve is raised to 16 MB. netmux.vcxproj set
  none, so the build took MSBuild's 1 MB default while the recursion
  limit is calibrated against a Linux-sized stack -- measured on MSVC
  x64, 1 MB crashed at 58 to 60 levels. The reserve is address space,
  not committed memory. netmux.vcxproj's include and library paths are
  now relative to the project instead of hardcoded.

- - Other fixes. An oversized sitelock CIDR prefix is rejected instead of
  silently truncating; the CResultsSet field walk is restored, so a
  result set with two or more columns no longer returns pointers into
  the middle of field data (reachable through rsrec/rsnext, and only
  with a configured SQL slave); an EVP_MD_CTX is released rather than
  leaked when a digest algorithm name is unknown; and sqlslave is
  const-correct so the module compiles with modern g++.

Configuration and behaviour changes
- ------------------------------

No configuration changes are required and no softcode changes are
needed. One malformed-input behaviour changes: a sitelock prefix too
large to fit in an int -- /4294967296, for example -- is now rejected
rather than truncating to 0 and producing a 0.0.0.0 mask that matched
every address. Every prefix that is valid today parses identically.

Download
- ------------------------------

Unix
- ----

Full source (tar.gz):
mux-2.13.0.16.unix.tar.gz
SHA256: 282ced57161487b49434317992619428df41f7e4bb868131974ff8532ccc5c1e

Full source (tar.bz2):
mux-2.13.0.16.unix.tar.bz2
SHA256: d6d137df9b9e3dba2c0b3fd901a222ccbaac6b4682e545a8b8b2347db47cd941

Patch from 2.13.0.15:
mux-2.13.0.15-2.13.0.16.unix.patch.gz
SHA256: cd601cbbd51509237dd6dca0b8ac1225292e785a4952a0c987eb9cbb19b86e9b

Windows
- -------

Binary (zip):
mux-2.13.0.16.win32.bin.zip
SHA256: 80372903043c7d1b46bacc252bde8d97cc68b2d32b09c5553dd7b03e6ee8a2b6

Binary (7z):
mux-2.13.0.16.win32.bin.7z
SHA256: 4f345f30a6468557ade24592328493310b57c7d9cc91349f1e506ad0b01efe8c

Full source (zip):
mux-2.13.0.16.win32.src.zip
SHA256: afda654afb48f72592db6ce06e191ddbbd2b9fe453b6e81c2f3c82a784c7073c

Full source (7z):
mux-2.13.0.16.win32.src.7z
SHA256: 0ca2c2adee9e52882645bee14c39d848e65d74aca74cccbb06b994cad517540c

Binary patch from 2.13.0.15 (zip):
mux-2.13.0.15-2.13.0.16.win32.bin.patch.zip
SHA256: ce1e2a3aacbdccf40cf06abe61c6a9ef8299f25f8ad624ec11e457f7674aaa37

Binary patch from 2.13.0.15 (7z):
mux-2.13.0.15-2.13.0.16.win32.bin.patch.7z
SHA256: 3f13f51d292714ac5ef97b5c2b9a8ff81b9840f8cdbe4b8dadb94963ad48a050

Source patch from 2.13.0.15 (zip):
mux-2.13.0.15-2.13.0.16.win32.src.patch.zip
SHA256: 6c57de024ed5d8112a340a9c04df78e1c08eef327cda7c369f0a1401a11a007b

Source patch from 2.13.0.15 (7z):
mux-2.13.0.15-2.13.0.16.win32.src.patch.7z
SHA256: bda886c5bb5e8ff3ad07f7c1da38a99c2814b68a35e7de53d7f6c82d70110801

All files are GPG-signed (.asc).

Report bugs to brazi...@gmail.com.

- -- Brazil

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE8GWFNwJrhRGk25uvF80K5PxQP7EFAmp1k5AACgkQF80K5PxQ
P7Hv2hAAtK26zl27KGIess9VEPf8MdFCzNIlfRPPVRKrn8TkAeTEX1WhtVFVvTw8
mzIfJz1LoGSkyUnV9rRCIoCyICB9eHhLcd4picJzL16QH59CITJd1DLyzetzWTLO
aKPBRmciKSJTVhbxu6/GAR8N8OgngTQADp3x3bex8NpmJanhpU+K3586lxb0/riO
PrDr2W4wkfHsFtyltLoDKlKg2rUgLrzESVDbBS+kUQTLXDuLMf8IC+o9MkdL/Fqe
NIxhfWml7RWLvQr8gPaeaWzZaH9z1AmEeESHyfjpz+z4xE6wo2q6R08dYsDTFBlJ
jaEgMPSjxYctxLRPkyXqBx4TceKtMIUhV1DSgWL2WmR8ifCaZVpvb26+KDuFe+ct
lCSeNKqvbW9Y0qpp4BuClGFJYDz4labcNjA26aoc07umgRlYADnN1ndpsXPKPX4N
rnJMA+B9P5qxwQbxEjAa+F7qf10qtBx8TTKZbm+xmQPZsVniT/zoxt7j17wBzAI8
b7jD47p6hrqIO0mzXYX1ZgkUUqRSAESauCTcS/dctG/O4GJMFawjRk/axlUB65tM
MPLjrbqU5a1tV372d66yz01nbdthlKzu7/43J2OgI+M7+jjS5qB4o/LOi/WbsvTh
xCS0OgsIWlZLHEertNOH04SbskNcOjM4VEB5a2Dy0sVsBI6vgAA=
=gqso
-----END PGP SIGNATURE-----

Reply all
Reply to author
Forward
0 new messages