Bug #10483

Possible segmentation fault in WebSession during application creation

Added by Steven Köhler 8 months ago. Updated 7 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


While tracing an issue in my application I somehow managed to get it in an invalid state during application construction and thus caused an exception, which was not caught in the constructor, as it was completely unexpected. Since I anticipated such a case might occur I added some error handling in the function that creates the application, and that is passed to WServer::addEntryPoint, which looks something like this:

auto createFn = [](/* params */) {
  std::unique_ptr<MyApp> app;
  try {
    app = std::make_unique<MyApp>(/* params */);
    return app
  } catch (...) {
    /* error handling */
  return app; // = nullptr at this point

It seemed to be a reasonable idea not to relay an unhandled exception to Wt, but to indicate a failed construction with a nullptr, which is the only valid return value for createFn in case the construction failed. Or so I thought... It turned out, that this causes a segmentation fault in WebSession::start, which kills the whole server, since Wt lacks a null check there. Wt's whole application creation is wrapped in a try-catch-block, but since segmentation faults cannot be caught that way, it just crashes despite the intended error handling.

bool WebSession::start(WebResponse *response) {
  try {
    app_ = controller_->doCreateApplication(this).release();
    if (!app_->internalPathValid_)
      if (response->responseType() == WebResponse::ResponseType::Page)
  } catch (std::exception& e) {

It is an easy fix in my application to just remove my custom error handling or rethrow the exception, but it seems to be kind of counter-intuitive to relay an unhandled exception to prevent a server crash.

Therefor I suggest some additional error handling in WebSession::start to handle nullptr, especially since it is not documented that a nullptr must not be returned and since I can image some cases that lead to a returned nullptr. In any case it should never be possible to kill the whole server like this, but instead produce an HTTP 500 error like when unhandled exceptions occur.

I already implemented the proposed fix an created a pull request:


Updated by Roel Standaert 7 months ago

  • Status changed from New to InProgress
  • Assignee set to Roel Standaert
  • Target version set to 4.8.0

Updated by Roel Standaert 7 months ago

  • Status changed from InProgress to Resolved
  • Assignee changed from Roel Standaert to Steven Köhler



Updated by Roel Standaert 7 months ago

  • Target version changed from 4.8.0 to 4.7.3

Updated by Roel Standaert 7 months ago

  • % Done changed from 0 to 100

Updated by Roel Standaert 7 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF