Throwing exception crashes python

[empty-set-math]

I am throwing a custom exception, registering that exception with my module and testing this behavior.
I have done this following the examples set in documentation here.
I have found that in the trivial cases, everything works as expected. But, when my function signatures include a string or when throwing the exception in a class method, the kernel dies.

The following is an example which reproduces this:

#include <pybind11/pybind11.h>
#include <stdexcept>

namespace py = pybind11;

class NotImplementedError : public std::logic_error {
 public:
  NotImplementedError(const char* __s) : std::logic_error(__s){};
};

struct Foo {
  void bar() {
    throw NotImplementedError("");
  }
};

PYBIND11_MODULE(test, m) {
  // Register the C++ NotImplementedError to raise corresponding the Python
  // version.
  py::register_exception_translator([](std::exception_ptr p) {
    try {
      if (p)
        std::rethrow_exception(p);
    } catch (const NotImplementedError& e) {
      PyErr_SetString(PyExc_NotImplementedError, e.what());
    }
  });

  // Throw the error, raising the error to python.
  m.def(
      "throw_not_implemented_error",
      []() -> void { throw NotImplementedError("Some message"); },
      "Throws a NotImplementedError.");

  // Throw the error, raising the error to python.
  m.def(
      "throw_not_implemented_error_int",
      [](int x) -> void { throw NotImplementedError("Some message"); },
      "Throws a NotImplementedError.");

  // Throw the error, killing the interpreter.
  m.def(
      "throw_not_implemented_error_string_will_crash_the_interpreter",
      [](const char* s) -> void { throw NotImplementedError("Some message"); },
      "Kills the kernel.");

    py::class_<Foo>(m, "Foo")
      .def(py::init<>())
      // Throw the error, killing the interpreter.
      .def("bar", &Foo::bar, "Throws a NotImplementedError and kills the kernel");
}

Certainly I am doing something incorrectly here, but am at a loss as to where.

[empty-set-math]

This is a duplication of this thread.
My issue was a result of a conflict between multiple version of clang on my system.