passenger 6.0.26 → 6.0.27

data/dev/copy_boost_headers

@@ -26,7 +26,6 @@
 ESSENTIALS = [
   "boost/*regex*",
   "boost/algorithm/string",
-  "boost/asio*",
   "boost/atomic",
   "boost/bind",
   "boost/chrono*",
@@ -83,14 +82,9 @@ EXCLUDE = [
   "libs/regex/src/usinstances.cpp",
   "boost/atomic/detail/windows.hpp",
   "boost/regex/icu.hpp",
-  "boost/asio/detail/win*",
-  "boost/asio/detail/impl/win*"
 ]
 PROGRAM_SOURCE = %q{
   #include <boost/aligned_storage.hpp>
-  #include <boost/asio.hpp>
-  #include <boost/asio/ssl.hpp>
-  #include <boost/asio/steady_timer.hpp>
   #include <boost/atomic.hpp>
   #include <boost/bind/bind.hpp>
   #include <boost/chrono.hpp>
@@ -117,6 +111,7 @@ PROGRAM_SOURCE = %q{
   #include <boost/pool/object_pool.hpp>
   #include <boost/predef.h>
   #include <boost/predef/other/endian.h>
+  #include <boost/preprocessor/stringize.hpp>
   #include <boost/random/random_device.hpp>
   #include <boost/random/uniform_int_distribution.hpp>
   #include <boost/ref.hpp>
@@ -135,14 +130,12 @@ PROGRAM_SOURCE = %q{
   #include <boost/thread/once.hpp>
   #include <boost/thread/tss.hpp>
   #include <boost/typeof/typeof.hpp>
-  #include <boost/unordered_map.hpp>
   #include <boost/version.hpp>
   #include <boost/weak_ptr.hpp>
 // Included despite not used in Passenger
   #include <boost/thread/thread_time.hpp>
   #include <boost/cregex.hpp>
   #include <boost/pointer_cast.hpp>
-  #include <boost/asio.hpp>
 }
 
 require 'fileutils'
@@ -189,9 +182,8 @@ def copy_boost_files(patterns, exclude = nil)
 end
 
 def copy_essential_files
-  exclude = []
-  EXCLUDE.each do |pattern|
-    exclude.concat(Dir["#{BOOST_DIR}/#{pattern}"])
+  exclude = EXCLUDE.flat_map do |pattern|
+    Dir["#{BOOST_DIR}/#{pattern}"]
   end
   copy_boost_files(ESSENTIALS, exclude)
 end
@@ -203,9 +195,6 @@ def prepare
 end
 
 def cleanup
-  FileUtils.rm_rf("boost/asio/detail/old_win_sdk_compat.hpp")
-  FileUtils.rm_rf("boost/asio/win32")
-  FileUtils.rm_rf("boost/asio/windows")
   FileUtils.rm_rf("boost/atomic/detail/caps_windows.hpp")
   FileUtils.rm_rf("boost/atomic/detail/core_ops_windows.hpp")
   FileUtils.rm_rf("boost/atomic/detail/fence_ops_windows.hpp")

data/dev/index_cxx_dependencies.rb

@@ -6,7 +6,6 @@ SEARCH_PATHS = [
   "src/agent",
   "src/cxx_supportlib",
   "src/cxx_supportlib/vendor-copy",
-  "src/cxx_supportlib/vendor-modified/websocketpp",
   "src/cxx_supportlib/vendor-modified",
   "test/cxx"
 ]
@@ -52,6 +51,7 @@ EXCLUDE_NAMES = %w{
   cstdlib
   cstddef
   cstdarg
+  cstdint
   cstring
   ctime
   csignal

data/doc/AiInstructions.md

@@ -0,0 +1,112 @@
+This is codebase of the Passenger application server.
+
+## Architecture summary
+
+### Multi-process
+
+- Web server (Apache or Nginx, both with the Passenger module loaded). Only simple I/O processing and lifecycle management of the Passenger Watchdog Agent.
+- Passenger Watchdog Agent: spawns and supervises Passenger Core Agent and a bunch of other periodic helper tasks.
+- Passenger Core Agent. Most logic happens here. Main request processing (Controller), spawns (SpawningKit) and supervises (ApplicationPool) application processes, keeps track of various statistics. Has an API server (separate socket) for management operations (used by e.g. `passenger-status`).
+
+### HTTP request routing path
+
+1. Requests are commonly first received by the web server, which forwards request to Passenger Core. Core's Controller subsystem then processes it.
+2. Requests may also be directly received by Passenger Core (Passenger Standalone + "builtin" engine).
+3. Passenger Core's Controller subsystem uses ApplicationPool to determine whether to spawn an application process or which process to route request to. Connects to the app's socket or reuses keepalive socket.
+4. Response from app forwarded back to the connecting client (could be a real client or the web server).
+
+### Applcation processes lifecycle management and request routing
+
+- Main logic in ApplicationPool (src/agent/Core/ApplicationPool). Keeps track of which application Processes exist. Contains logic for routing a request to best Process.
+- Pool has many Groups. Group has many Processes (for application processes). Process has many Sockets (of which one is the "main socket" for receiving requests).
+- Spawning logic outsourced to SpawningKit.
+
+### Application spawning
+
+- Main logic in SpawningKit (src/agent/Core/SpawningKit)
+- Creates subprocess, sets up appropriate environment:
+  - Basic things like working directory and UID.
+  - But also a temporary directory for subprocesses to communicate its spawning progress with the parent process.
+- Once generic subprocess environment setup is done, exec()s a language-specific "loader" which handles further language-specific spawning. For example for Ruby apps, rack-preloader.rb and rack-loader.rb are applicable.
+- Two spawning modes:
+  - "direct" is a normal execution of the app without fancy tricks. Uses "loaders".
+  - "smart" uses preforking. Preforking server is started through a "preloader". SpawningKit communicates with preforking server to perform further actual spawning.
+
+## C++ tech stack
+
+- Agent written in C++
+- C++11
+- Boost. But prefer C++11
+
+### HTTP and non-blocking I/O handling
+
+- ServerKit (src/cxx_supportlib/ServerKit)
+- libev
+- Some parts use libuv. Integrates with libev via SafeLibev.h
+
+## Important directories
+
+- src: most source code
+- src/agent: various agents
+- src/agent/Core
+- src/agent/Watchdog
+- src/nginx_module
+- src/apache2_module
+- src/cxx_supportlib: C++ support library
+- src/helper-scripts: various helper scripts, including SpawningKit language-specific (pre)loaders.
+
+## Build system
+
+- Building agents: `drake -j4 nginx` (for concurrent building) or `rake nginx`
+- Building C++ test suite: `drake -j4 test:cxx:build` (for concurrent building) or `rake test:cxx:build`
+
+## Special files
+
+*.cxxcodebuilder: a Ruby DSL for generating C/C++ code: https://github.com/phusion/cxxcodebuilder/blob/master/README.md
+Similar in philosophy as Rails's Jbuilder.
+Convention: AutoGeneratedFoo.c.cxxcodebuilder generates AutoGeneratedFoo.c
+
+## Config handling
+
+Apache/Nginx:
+- Config flows from the web server to the Core to the app.
+- There are three levels of configs: global, per-application, per-request. They're centrally registered:
+  - src/ruby_supportlib/phusion_passenger/apache2/config_options.rb
+  - src/ruby_supportlib/phusion_passenger/nginx/config_options.rb
+- Module C/C++ code for managing these configs are autogenerated by build system from config_options.rb.
+
+Passenger Standalone:
+- Config flows from the Passenger Standalone CLI tool, either to Nginx ("nginx" engine mode) or directly to Core ("builtin" engine mode).
+- Config options are centrally registrered in src/ruby_supportlib/phusion_passenger/standalone/config_options_list.rb.
+- Nginx engine: config to pass from CLI to Nginx, are registered in the Nginx config templates in resources/templates/standalone.
+- Builtin engine: config to pass from CLI to Core (via Watchdog) through src/ruby_supportlib/phusion_passenger/standalone/start_command/builtin_engine.rb build_daemon_controller_options.
+
+In the Core Controller there are also three levels of configs: global (via ConfigKit), per-application and per-request. Per-application and per-request configs are fetched from HTTP headers. Per-application configs are passed to ApplicationPool options. Per-request configs are sometimes (but usually not) passed to ApplicationPool.
+
+Keep config option naming between the different integration modes consistent, yet adhering to naming conventions for that integration mode. Example: Apache=PassengerStartTimeout, Nginx=passenger_start_timeout, Standalone=start_timeout (config file) or --start-timeout (CLI arg).
+
+## Coding guidelines
+
+### General
+
+- Make the smallest changes to existing interfaces as possible. Be averse to rewriting things.
+- Keep code readable and focused by splitting smaller or side concerns into functions.
+- Unless the code is trivial and small, prefer not to duplicate code: prefer splitting to common functions.
+- When appropriate, consult design aspects documentation in doc/DesignAspects.
+
+### For C++
+
+- Don't introduce direct libev/libuv dependency in components that don't already use libev/libuv/ServerKit.
+- Prefer using internal utility library.
+  - Prefer oxt/system_calls.hpp wrappers (e.g. oxt::open) over direct syscalls. If no wrapper available, loop until no EINTR.
+  - Consult Utils.h (general utils), IOUtils.h (I/O), FileTools/*.h (file operations).
+  - Prefer FileDescriptor or safelyClose() over close().
+- Mind security: see TempFileHandling.md; prefer safeReadFile() for reading files.
+- Before modifying .cpp files, research corresponding header files.
+- Be careful about object lifetimes. For example, if an object must live longer than the scope, consider storing it as a class field.
+
+#### When working on a ServerKit server (including Core Controller)
+
+- Working objects whose lifecycle are scoped by the request, are to be stored in the corresponding Request struct.
+- When adding stuff to the Request struct, mind proper initialization and deinitialization. Update the initializeRequest and deinitializeRequest methods.
+- When performing an async operation that's not cancellable, use refRequest to keep the Request object alive until the async callback is called. In the callback, check for req->ended().

data/doc/CxxMockingStrategy.md

@@ -0,0 +1,42 @@
+# C++ mocking strategy
+
+- We don't use any mocking library.
+- We implement mocking by splitting mockable code to protected virtual methods. Inside test suites, we create a subclass in which we override the methods we want to mock.
+- Best practices for the override:
+   - Opt-in for mocking on a per-test basis.
+   - When not opted-in, call the parent class's method instead of duplicating its code.
+
+Example:
+
+```c++
+class Greeter {
+protected:
+    virtual const char *name() {
+        return "john";
+    }
+
+public:
+    void greet() {
+        std::cout << "hello " << name() << std::endl;
+    }
+};
+
+// In the test suite:
+class TestGreeter: public Greeter {
+protected:
+    virtual const char *name() override {
+        if (mockName != nullptr) {
+            return mockName;
+        } else {
+            return Greeter::name();
+        }
+    }
+
+public:
+    const char *mockName; // Set to non-nullptr to mock the name
+
+    TestGreeter()
+        : mockName(nullptr)
+        { }
+};
+```

data/doc/CxxTestingGuide.md

@@ -0,0 +1,110 @@
+# C++ testing guide
+
+C++ tests use a modified version of the [Tut test framework](https://mrzechonek.github.io/tut-framework/).
+
+Test files are placed in test/cxx/SomethingTest.cpp.
+
+## Test suite example
+
+```c++
+#include <TestSupport.h> // Always include this
+#include <Something.h> // The class to test
+
+// Always use these namespaces
+using namespace std;
+using namespace boost;
+using namespace Passenger;
+
+namespace tut {
+    // Each test suite has a corresponding context struct, created and
+    // deleted for every test case. You can put test case-local state here.
+    struct SomethingTest: public TestBase {
+        Something something;
+    };
+
+    TEST_METHOD(1) {
+        set_test_name("Description for test 1");
+
+        // Test logic here.
+        // `this` is a SomethingTest instance.
+
+        ensure_equals("Description for assertion 1", 1, something.foo());
+        ensure_equals("Description for assertion 2", 2, something.bar());
+    }
+
+    TEST_METHOD(2) {
+        set_test_name("Description for test 2");
+
+        // Test logic here.
+        // `this` is a SomethingTest instance.
+    }
+}
+```
+
+## Available assertions
+
+ - `ensure([description,] bool)` — Asserts argument is true.
+ - `ensure_not([description,] bool)`
+ - `ensure_equals([description,] actual, expected)` — Asserts `actual == expected`.
+ - `ensure_not_equals([description,] actual, expected)`
+ - `ensure_gt(description, a, b)` — Asserts `a > b`.
+ - `ensure_distance([description,] a, b, d)` — Asserts the distance between `a` and `b` is <= `d`.
+ - `fail(description)` — Fails the test case.
+
+### Special assertions for multithreaded code
+
+ - `EVENTUALLY(deadlineSeconds, code)` — Asserts that "something eventually happens".
+
+   Runs `code` in a loop, sleeping for 10 msec each time, until code set `result = true` or timeout.
+
+   Example:
+
+   ```c++
+   EVENTUALLY(5,
+     result = fileExists("foo.txt");
+   );
+   ```
+
+   Notes:
+
+    - `code` is in a new lexical context, so defining variables there is fine.
+    - Since EVENTUALLY is for multithreaded use cases, remember to synchronize access to shared state.
+
+- `EVENTUALLY2(deadlineMsec, sleeptimeMsec, code)` — Same as EVENTUALLY but with finer timing customization.
+
+- `SHOULD_NEVER_HAPPEN(deadlineMsec, code)` — Asserts that "something should never happen".
+
+  Runs `code` in a loop for `deadlineMsec`. If `code` sets `result = true`, the test fails.
+
+  Example:
+
+  ```c++
+  SHOULD_NEVER_HAPPEN(1000,
+    result = checkSocketDisconnected();
+  );
+  ```
+
+  The notes for `EVENTUALLY()` also apply here.
+
+## Mocking
+
+See [C++ mocking strategy](CxxMockingStrategy.md).
+
+## Running tests
+
+Prerequisite: ensure `test/config.json` exists. Refer to its `.example` file.
+
+```bash
+# Run all test suites
+rake test:cxx GROUPS=SomethingTest
+
+# Run specific test suites
+rake test:cxx GROUPS=SomethingTest,AnotherTest
+
+# Run specific tests by number
+rake test:cxx GROUPS=SomethingTest:1,3
+
+# Attach to GDB or LLDB
+rake test:cxx GROUPS=SomethingTest GDB=1
+rake test:cxx GROUPS=SomethingTest LLDB=1
+```

data/doc/DesignAspects/LimitedGemDependencies.md

@@ -2,38 +2,46 @@
 
 ## Context
 
-- We provide native packages (APT/YUM) for Passenger.
-- Passenger has a bunch of tools (e.g. `bin/passenger-status`, `helper-scripts/backtrace-sanitizer.rb`, `helper-scripts/prespawn`) that are written in Ruby. When Passenger is natively packaged, we ensure that these tools run in the "system" Ruby.
-- On Debian-based systems, the OS package repositories may supply multiple Ruby versions. So our native packaging can't assume a single Ruby version.
+1. Passenger can be installed through various ways, including as a Ruby gem (via Gemfile) or via native packages (APT/YUM).
+2. Passenger has a bunch of tools (e.g. `bin/passenger-status`, `helper-scripts/backtrace-sanitizer.rb`, `helper-scripts/prespawn`) that are written in Ruby.
+   - Tools in `bin/` might be run with gem bundle activation (only if Passenger is installed via Gemfile).
+   - Tools in `helper-scripts/` are never run with gem bundle activation.
+   - All these tools are run in either the "system" Ruby (if Passenger is natively packaged), or the Ruby the app runs in (if Passenger is installed via Gemfile).
+3. On Debian-based systems, the OS package repositories may supply multiple Ruby versions. So our native packaging can't assume a single Ruby version.
 
-This raises the question of how to deal with Passenger's own gem dependencies. An analysis of possible strategies and their implications/tradeoffs:
+This context raises interesting challenges that other Ruby apps don't have to deal with:
 
-1. If the OS package repositories supply dependent gems, then our native packages can depend on those directly.
+ - (1) implies that we can't rely solely on Bundler to take care of our gem dependencies.
+ - (2) and (3) imply that we can't rely on only a single Ruby version being used. Different components of Passenger are potentially run in different Rubies, sometimes with and sometimes without bundle activation.
 
-   Drawbacks:
+What does this mean for the number of gems we can depend on? An analysis of possible strategies and their implications/tradeoffs:
 
-    - Limited selection of gems.
+1. If the OS package repositories supply dependent gems, then our native packages can depend on those directly.
 
-2. We package the gem dependencies ourselves. In addition, any dependency with native extensions must be packaged separately, once for each Ruby version installable through the native OS package repositories.
+   Drawbacks: limited selection of gems and versions.
 
-   Drawbacks:
+2. We publish native packages for each gem dependency. In addition, any dependency with native extensions must be packaged separately, once for each Ruby version installable through the native OS package repositories.
 
-    - More work for us.
+   Drawbacks: lots of work for us.
 
 3. We vendor the gem dependencies within the native packages. In addition, any dependency with native extensions must be vendored separately, once for each Ruby version installable through the native OS package repositories.
 
+   Drawbacks: more work for us. Less than option 2, but still significant.
+
 ## Decision
 
 We pick strategy 1.
 
 ## Consequences
 
-- Any gems that the written-in-Ruby tools depend on, must either be available through OS repositories, or must be a Ruby standard library gem.
+- **Limited gem selection**: any gems that the written-in-Ruby tools depend on, must either be available through OS repositories, or must be a Ruby standard library gem.
+  - For example "json" is a good gem we can depend on, but "pry" is not.
   - All such dependencies must be specified in the Passenger gemspec.
-- Development-related Passenger Ruby code can depend on any gem, since they're not included in native packages.
+- **Code with broad version compatibility**: Since we can't rely on specific gem versions, we must use gems in a way that's compatible with a wide number of gem versions.
+- **Development code can YOLO with gem dependencies**: Development-related Passenger Ruby code can depend on any gem, since development code is not included in native packages.
   - All such dependencies must be specified in the Passenger Gemfile.
 
 ## See also
 
-- [No gem activation during Ruby loader initialization](NoGemActivationDuringRubyLoaderInitialization.md)
-- System Ruby runner (only used in Debian packages): `packaging/debian/debian_specs/passenger/passenger_system_ruby.c.erb`
+- [No gem activation during Ruby loader initialization](NoGemActivationDuringRubyLoaderInitialization.md) — a special case where we can't load *any* gem, whether or not those gems are packaged by the OS.
+- System Ruby runner (only used in Debian packages): `packaging/debian/debian_specs/passenger/passenger_system_ruby.c.erb` — how we enforce that in Debian packages, tools in `bin/` only run in the system Ruby.

data/doc/TempFileHandling.md

@@ -0,0 +1,15 @@
+# Handling of temp files
+
+Always use unpredictable filenames for temp files. Failing to do so makes us vulnerable to symlink attacks, TOCTOU race conditions, file squatting, or even information disclosure and privilege escalation.
+
+Always use a tempfile creation strategy that atomically:
+1. Finds a free filename, *and*,
+2. Reserves that filename (failing if it already exists), *and*,
+3. Restrict permissions to only the intended user (e.g. mode 0600),
+Doing these non-atomically makes us vulnerable to TOCTU race conditions.
+
+Implementation tips:
+- Use getSystemTempDir()
+- Use mkstemp() for single, regular files. Don't use it for non-regular files such as Unix sockets; use a temp dir instead.
+- Use mkdtemp() for creating a temp dir or for storing temp non-regular files.
+- mktemp() is bad.

data/passenger.gemspec

@@ -28,7 +28,7 @@ Gem::Specification.new do |s|
   # See doc/DesignAspects/LimitedGemDependencies.md
   s.add_dependency 'rake', '>= 12.3.3'
   s.add_dependency 'rack', '>= 1.6.13'
-  s.add_dependency 'rackup', '>= 2.0.0'
+  s.add_dependency 'rackup', '>= 1.0.1'
 
   s.files = Dir[*PhusionPassenger::Packaging::GLOB] -
     Dir[*PhusionPassenger::Packaging::EXCLUDE_GLOB]

data/resources/templates/standalone/server.erb

@@ -42,6 +42,7 @@ passenger_enabled on;
 <%= nginx_option(app, :app_type) %>
 <%= nginx_option(app, :startup_file) %>
 <%= nginx_option(app, :app_start_command) %>
+<%= nginx_option(app, :app_connect_timeout) %>
 <%= nginx_option(app, :start_timeout) %>
 <%= nginx_option(app, :min_instances) %>
 <%= nginx_option(app, :max_request_queue_size) %>

data/src/agent/Core/ApiServer.h

@@ -32,7 +32,6 @@
 #include <oxt/thread.hpp>
 #include <string>
 #include <cstring>
-#include <exception>
 #include <sys/types.h>
 
 #include <jsoncpp/json.h>

data/src/agent/Core/ApplicationPool/AbstractSession.h

@@ -52,10 +52,19 @@ public:
 	virtual StaticString getProtocol() const = 0;
 	virtual unsigned int getStickySessionId() const = 0;
 	virtual const ApiKey &getApiKey() const = 0;
+	/** The connection fd that was established by \c initiate(), or -1 if not initiated yet. Note that this fd is non-blocking. */
 	virtual int fd() const = 0;
 	virtual bool isClosed() const = 0;
 
-	virtual void initiate(bool blocking = true) = 0;
+	/**
+	 * Initiates a non-blocking connect to the application socket, or reuse an existing connection.
+	 *
+	 * @return Whether the non-blocking connect finished (true) or whether you need to wait for it (false).
+	 * @throws SystemException Something went wrong.
+	 * @throws RuntimeException Something went wrong.
+	 * @throws boost::thread_interrupted A system call has been interrupted.
+	 */
+	virtual bool initiate() = 0;
 
 	virtual void requestOOBW() { /* Do nothing */ }
 

data/src/agent/Core/ApplicationPool/Group/ProcessListManagement.cpp

@@ -171,7 +171,7 @@ Group::findBestProcessPreferringStickySessionId(unsigned int id) const {
  *
  * If there is no process that can be routed to, then returns nullptr.
  *
- * @post result != nullptr || result.canBeRoutedTo()
+ * @post result == nullptr || result.canBeRoutedTo()
  */
 Process *
 Group::findBestProcess(const ProcessList &processes) const {

data/src/agent/Core/ApplicationPool/Group/SessionManagement.cpp

@@ -67,42 +67,57 @@ Group::route(const Options &options) const {
 		if (options.stickySessionId == 0) {
 			if (OXT_LIKELY(useNewRouting())) {
 				process = findBestProcess(enabledProcesses);
+				if (process != nullptr) {
+					assert(process->canBeRoutedTo());
+					return RouteResult(process);
+				} else {
+					return RouteResult(NULL, true);
+				}
             } else {
 				process = findEnabledProcessWithLowestBusyness();
-			}
-			if (process != nullptr) {
-				assert(process->canBeRoutedTo());
-				return RouteResult(process);
-			} else {
-				return RouteResult(NULL, true);
+				if (process && process->canBeRoutedTo()) {
+					return RouteResult(process);
+				} else {
+					return RouteResult(NULL, process == nullptr);
+				}
 			}
 		} else {
 			if (OXT_LIKELY(useNewRouting())) {
 				process = findBestProcessPreferringStickySessionId(options.stickySessionId);
+				if (process != nullptr) {
+					if (process->canBeRoutedTo()) {
+						return RouteResult(process);
+					} else {
+						return RouteResult(NULL, false);
+					}
+				} else {
+					return RouteResult(NULL, true);
+				}
 			}else{
 				process = findProcessWithStickySessionIdOrLowestBusyness(options.stickySessionId);
-			}
-			if (process != nullptr) {
-				if (process->canBeRoutedTo()) {
+				if (process && process->canBeRoutedTo()) {
 					return RouteResult(process);
 				} else {
-					return RouteResult(NULL, false);
+					return RouteResult(NULL, process == nullptr);
 				}
-			} else {
-				return RouteResult(NULL, true);
 			}
 		}
 	} else {
 		if (OXT_LIKELY(useNewRouting())) {
 			process = findBestProcess(disablingProcesses);
+			if (process != nullptr) {
+				assert(process->canBeRoutedTo());
+				return RouteResult(process);
+			} else {
+				return RouteResult(NULL, true);
+			}
 		} else {
 			process = findProcessWithLowestBusyness(disablingProcesses);
-		}
-		if (process != nullptr) {
-			assert(process->canBeRoutedTo());
-			return RouteResult(process);
-		} else {
-			return RouteResult(NULL, true);
+			if (process && process->canBeRoutedTo()) {
+				return RouteResult(process);
+			} else {
+				return RouteResult(NULL, process == nullptr);
+			}
 		}
 	}
 }

data/src/agent/Core/ApplicationPool/Group.h

@@ -42,7 +42,6 @@
 #include <sys/types.h>
 #include <sys/stat.h>
 #include <cstdlib>
-#include <cassert>
 #include <MemoryKit/palloc.h>
 #include <WrapperRegistry/Registry.h>
 #include <Hooks.h>

data/src/agent/Core/ApplicationPool/Implementation.cpp

@@ -23,12 +23,9 @@
  *  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
  *  THE SOFTWARE.
  */
-#include <typeinfo>
-#include <algorithm>
 #include <utility>
 #include <cstdio>
 #include <sstream>
-#include <limits.h>
 #include <unistd.h>
 #include <boost/make_shared.hpp>
 #include <boost/ref.hpp>