It turns out this was already enabled on MSVC (due to /EHsc), but let's
enable it on other platforms as well.
Exception handling comes with a huge caveat: SourceMod and SourcePawn
are not exception safe. Not only do they predate usable STL (C++11),
they often predate C++03, and sometimes even C++ itself. There are many
places we do not use RAII, or where we accumulate state in a way that
cannot be interrupted.
By enabling exceptions, we are NOT inviting general try/catch. We are
still assuming that a `throw` anywhere within SourceMod will ultimately
result in a crash.
However, as we enable more and more STL, we are losing the ability to
gracefully handle constructor failures and malloc failures. So try-catch
is now enabled. It should only be used in the narrowest of
circumstances:
- When an exception can be thrown by a library call, and
- There is no way "a priori" to tell if an exception will be thrown
(for example, std::bad_alloc or std::system_error), and
- Handling the exception is meaningful.
Generally malloc failures should not be considered meaningful. Once
memory is exhausted, the program will crash or be OOM-killed, so there's
no point in handling the failure. However, cases where the allocation
amount is variable may be meaningful to handle. A simple example would
be CDataPack, where if a plugin leaks entries, it's better to handle
this gracefully given that vector growth is geometric. Another example
might be reads of a massive file or network request into a buffer.
These cases should be rare, given that memory pressure is usually
fatal to srcds anyway. But if you've decided to handle an exception,
the try-catch block should be as narrow as possible. For example,
the following is erroneous:
ke::Maybe<SomeGiganticThing> object;
try {
object.init();
} catch (const std::bad_alloc&) {
}
`ke::Maybe` is not threadsafe, and this can leak. Basically, do as
little as possible in try blocks, and use them sparingly, because
they're very difficult to audit.
We are also not inviting use of `throw`, as auditing it is even more
complex than try/catch. It is better to abort(), or use boolean
returns and two-stage object initialization.
Our official builds use clang-3.4 (for macOS) and clang-3.8 for Linux.
Linux uses libstdc++-4.9. Make sure these two compilers are being tested
and that libstdc++-4.9 is being used for STL.
Add a macOS builder to get coverage there. This will use a newer
clang than we actually use, but as opposed to the linux builder will
test the platform-specific bits.
Finally, use the latest GCC and clang versions from a bionic image, so
we have some coverage of a popular distribution.
This patch removes almost all of the existing platform-specific
ThreadSupport code, as well as code derived from it. It is now
implemented on top of C++11 threads and is much simpler.
This is the first inclusion of STL in SourceMod. Mac and Windows are
allowed to dynamically link to their respective implementations. On
Linux, libstdc++ is statically linked, except in the cases where it was
already dynamically linked (csgo, blade).
IEventSignal has been retained because sourcemod-curl-extension relies
on it. As written, it is impossible to use as a condition variable,
because the caller does not have access to the underlying mutex. There
is no way to make this API safe or non-racy, so extensions relying on
it should switch to C++11 threads.
ThreadWorker is now pared down and does not interact or inherit from
BaseWorker in any way. Basic functionality has been tested. Since it is
not used anywhere in SourceMod, or seemingly in any repository on
GitHub, it's unclear whether it should even exist. But it has been
tested in this patch.
This change bumps the minimum macOS version to OS X 10.7, and the
minimum C++ standard level to C++14.
* Fix timelimit not correct for Black Mesa
Black Mesa is particular and use timelimit in seconds instead of minutes
* Update TimerSys.cpp
* Update TimerSys.cpp
* Update TimerSys.cpp
* Update TimerSys.cpp
The allocation size was still updated to the bigger size even if memory allocation failed. Trying to write to the supposedly available new space would overflow the heap and crash. Fixes#1233
* Fixed memory leak
When a pack was cleared or destroyed the String and Raw types could cause memory leaks. This happens when "position" is sitting at the end of the vector and can never get past the "if (pos >= elements.length())" statement. This means there is a memory leak in any plugin that clears/destroys a pack with strings and doesn't set the position to length-1 or less beforehand.
* datapack: Fix delete op on CDataPackType::Raw.
Co-authored-by: Kyle Sanderson <kyle.leet@gmail.com>
* DarkM: build-fix for engine msg caching
* style + promote ptr casting to uintptr_t.
* sync type to uintptr_t in pm.h
* return of the uint32_t
* update header.
* oh, right, unsigned int...
* Avoid losing console messages.
Buffers up to 16k bytes of SVC_Print if buffer would overflow, then sends chunks every frame.
Sends up to 2048 bytes per frame and does not split messages.
* UNTESTED! Switch to ke::LinkedList<ke::AString> for PrintfBuffer.
Switch from OnGameFrame to FramAction.
Fix compiling on Episode1 by essentially disabling the feature.
* UNTESTED! Cleanup on disconnect, passthrough for >= 2048 msgs
* try reference for CPlayer.
* fix
* remove m_PrintfStop
* remove m_PrintfStop
* ensure empty queue when netchan drops
* flip to serials.
* serials
* style
* Update PlayerManager.cpp
* lift consts to header.
* remove local const references
* ep1 static const
* flip to queue - fix serial on resched.
* Update PlayerManager.h
* Update PlayerManager.cpp
* Update PlayerManager.h
* am-deque.h
Co-authored-by: Kyle Sanderson <kyle.leet@gmail.com>
