Constructor initialization and object corruption - c++

Question

I have the following class structure, which initially threw a segfault. I have fixed the problem, but don't fully understand why the code initially through a segfault. I had a class B, a subclass of A, which,
after A initialised an object (InternalA) in the initialisation list
of the constructor, called a Run() method, which called a method on InternalA (InternalA.Start()) before calling a blocking method (io_service_.Run()), and so B's constructor never actually returned.
A separate thread would then try to access B, and call B->SendMsg(), but
all of InternalA's internal state would be corrupted. I fixed the problem by removing the blocking Run() method call from the constructor, and calling it afterwards.
Code shows me that the InternalA object does indeed get correctly initialised, but when calling b->SendMsg, InternalA is completely corrupted.
The issue that, using the new operator, the "real" address only gets assigned to the B* pointer after the constructor is returned (even though, when I check the address of b in the main thread, it is no longer null). If I instead malloced B, and subsequently called *b = B(), would it still be an issue, or would this then be architecture specific?
class B: public A
{
B(): A(arg1, arg2) { Run(); }
};
class A {
A(): InternalA()... {}
Run() {
InternalA.Start();
// Method does not terminate
io_service_.Run();
}
};
class InternalA {
InternalA(): io_service_(), map_(), id_(5) {}
void Start() {
std::cout << connections_.size() << std::endl;
}
void SendMsg() {
std::cout << connections_.size() << std::endl;
}
private:
boost::asio io_service_
std:map<X,Y> map_;
int id_;
};
int main() {
B* b = null;
std::thread t([&b] {b = new B()}); // Run() method gets called
usleep(200000);
b->SendMsg(); // All objects in InternalA are corrupted (point to invalid addresses
}

Answer 1

Before you can assign a value to b, that value has to be computed first. In your case, this computation (new B()) never returns, so you read uninitialized contents of the b in another thread.
Also, "a separate thread would then try to access B"? Without any checks organized to see if that "B" is actually there? You will have many hard-to-find bugs with such an approach.