https://gitlab.synchro.net/main/sbbs/-/commit/2fb010d6c3f20027e8b54d2a
Modified Files:
src/sbbs3/filterfile.hpp ftpsrvr.cpp mailsrvr.cpp main.cpp services.cpp Log Message:
Fix thread_down()-vs-cleanup() race causing heap corruption on Windows

thread_down() must be the very last operation in every server thread,
because cleanup() proceeds to destroy shared resources (active_clients, sockets, filterFile/trashCan objects) as soon as thread_count drops.
When a thread called thread_down() but continued accessing shared
resources afterward, cleanup() could destroy those resources
concurrently, corrupting the MSVC debug heap and triggering assertions
in strListFreeStrings during trashCan deletion.

Move thread_down() after all shared-resource access in:
- mailsrvr.cpp: smtp_thread, pop3_thread, sendmail_thread
- ftpsrvr.cpp: ctrl_thread (ftp_client_thread)
- services.cpp: 6 sites across js/native service threads
- main.cpp: passthru_socket_thread, events_thread

Also fix filterfile.hpp Rule of Five: delete copy/move operations
to prevent latent double-free, and remove unsafe default constructor
that left the pthread_mutex uninitialized.

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

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

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

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