• src/sbbs3/filterfile.hpp ftpsrvr.cpp mailsrvr.cpp main.cpp services.cp

    From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wed Mar 11 20:52:45 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/c8490b7429f47698e2988f63
    Modified Files:
    src/sbbs3/filterfile.hpp ftpsrvr.cpp mailsrvr.cpp main.cpp services.cpp websrvr.cpp
    Log Message:
    Support and use static instances of filterFile/trashCan objects in TCP servers

    For an unknown reason, deleting dynamically-created instances of these objects could cause MSVC debug-heap assertions under the right/rare circumstance.
    This change is a "punt" as it resolves the issue, but I don't understand why and have run out of ideas, tools, and patience trying to root-cause it.

    See issue #1099 for all the details.

    These classes now default-initialize every member since the default constructor does not and I didn't want to leave uninitized mutexes or strings potentially hanging around (before each ::init() member was called). That change alone did not fix the mysterious issue.

    These classes still support dynamic creation/deletion if/when we ever want to use that pattern again, e.g. to reproduce the mysterious issue (it's backward compatible).

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net
  • From Rob Swindell (on Windows 11)@VERT to Git commit to main/sbbs/master on Wed Mar 11 21:48:17 2026
    https://gitlab.synchro.net/main/sbbs/-/commit/9168bd69aaa634d555a248e1
    Modified Files:
    src/sbbs3/filterfile.hpp ftpsrvr.cpp mailsrvr.cpp main.cpp services.cpp websrvr.cpp
    Log Message:
    Create and use trashCan/filterFile reset() method to reset filter stats/times

    This reintroduces the behavior before the previous commit: where we were deleting the filter/trashcan objects upon server termination and the stats
    and timestamps would get reset/re-initialized when the server was initialized.

    I experimented with freeing the list in reset() and the old debug-heap assertions would return (now in the calls to reset() rather than the destructor), so that's more data for issue #1099.

    I don't think we really care about the memory allocated for the lists while
    the server is terminated. It'll get freed if/when the server is restarted
    or the process is terminated and the destructors are called. It's not a leak.

    ---
    þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net