https://gitlab.synchro.net/main/sbbs/-/commit/fb6c6aadd2d82c137cbeace2
Modified Files:
src/sbbs3/filterfile.hpp
Log Message:
Use explicitly initialized pthread_mutex_t instead of std::mutex

Using a default initializer for the std::mutex didn't resolve the issue
(crash in MSVCP140.dll).
Explicitly calling mutex.lock/unlock (rather than using a lock_guard) didn't resolve the issue.

trashCan constructor now calls filterFile constructor (to get the mutex initialized).

Resolves issue #1089 (with older MSVC++ runtime libraries)

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

https://gitlab.synchro.net/main/sbbs/-/commit/538aceb6f38bbf5d6927f523
Modified Files:
src/sbbs3/filterfile.hpp
Log Message:
Fix (new) mutex leak by destroying in destructor

As pointed out by Deuce in code review

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

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

https://gitlab.synchro.net/main/sbbs/-/commit/869eaababe5e96efa458b807
Modified Files:
src/sbbs3/filterfile.hpp
Log Message:
Add a comment about issue #1099 trigger to reset(), no effective change

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