Enabling Core Dumps and Interactive Debugging

Runtime segmentation faults in C++ network applications frequently occur during resource initialization phases. By default, Linux restricts core dump generation to conserve disk space. The ulimit -c command reveals the current limit; a return value of 0 indicates suppression. Executing ulimit -c unlimited permits the operating system to write memory snapshots upon fatal signals, though manually parsing these files can be cumbersome.

A more direct approach utilizes GDB with compiled debug symbols. Adding the -g flag to the compilation pipeline embeds source mapping data. Launching the executable via gdb ./server and issuing the run command immediately triggers a breakpoint at the faulting instruction. While the stack trace may point to standard I/O routines like __GI__IO_fputs, the actual defect typically originates in application logic preceding the system call.

Tracing Execution with Diagnostic Logging

Standard error output often contains application-level warnings prior to the crash. In this scenario, a MySQL connection refusal message appears consistently before termination. This narrows the investigation to the database connector initialization routine. The following function manages the creation of a predefined number of concurrent sessions:

void DbPool::initialize(const std::string& host, const std::string& account,
                        const std::string& secret, const std::string& catalog,
                        int session_limit, int network_port, bool quiet_mode) {
    endpoint = host;
    port = network_port;
    username = account;
    password = secret;
    schema = catalog;
    suppress_logs = quiet_mode;

    for (int iter = 0; iter < session_limit; ++iter) {
        MYSQL* handle = mysql_init(nullptr);

        if (!handle) {
            std::cerr << "ERROR: Handle allocation failed\n";
            std::exit(EXIT_FAILURE);
        }

        if (!mysql_real_connect(handle, endpoint.c_str(), username.c_str(),
                                password.c_str(), schema.c_str(), port, NULL, 0)) {
            std::cerr << "ERROR: Database connection rejected\n";
            std::exit(EXIT_FAILURE);
        }

        free_handles.push_back(handle);
        active_slots++;
    }
    semaphore.release(active_slots);
    max_capacity = active_slots;
}

To determine whether the crash occurs on the first iteration or after exhausting system quotas, instrumentation is inserted around the connection API. Adding iteration counters and boundary logs reveals the exact execution depth:

std::cout << "Attempting session #" << iter << std::endl;
// mysql_real_connect execution
std::cout << "Session #" << iter << established." << std::endl;

Identifying Parameter Misalignment

Execution logs consistently show successful connections for 151 iterations, followed by immediate termination on the 152nd attempt. This precise threshold indicates a hard limit is being breached rather than a random memory violation. Investigating the caller site in the web server configuration module reveals the invocation pattern:

void HttpEngine::setupDatabaseLayer() {
    auto& pool = DbPool::getInstance();
    pool.initialize("127.0.0.1", db_user, db_pass, app_schema,
                    3306, requested_connections, log_disabled);
}

The function signature expects the maximum session count as the fifth argument and the TCP port as the sixth. In the invocation above, these values are transposed. Passing the default MySQL port (3306) as the iteration bound causes the loop to attempt over three thousand connections. The database server enforces a per-client connection cap (often 151 or 152 by default). Once this limit is reached, mysql_real_connect returns a null pointer. Subsequent pool operations attempt to dereference this invalid handle, triggering the SIGSEGV signal. Swapping the arguments to align with the parameter declaration corrects the loop bound, prevents resource exhaustion, and eliminates the memory access violation.