There will be a crash if you close your Sender after the Connection has been closed.
To reproduce, compile and run the attached "crash_test.cc" file.
The test program is very simple. It creates Connection, Session, and Sender instances, then closes the connection explicitly followed by closing the sender. The closing of the sender causes an exception to be thrown as the connection is dead, but that is caught.
The crash happens when the Session object is destructed at the end of the test function. This causes the SenderContext from the sender to be destructed, which tries to close the underlying pn_link_t object to be freed, but that object refers to a deleted pn_connection_t object. The exception during Sender::close stopped the proper cleanup to be done.
The Sender::close method calls ConnectionContext::detach to disconnect it from its session. One problem here is that the Connection::close method made the connection forget all its sessions, but the sessions still remember their connection, including the underlying proton objects. The connection tries to reconnect to the broker and resets its internal connection, causing the proton connection object to be freed. It then tells all its sessions about this, but those are forgotten earlier. This means that we end up with pn_link_t objects that refer to a deleted pn_connection_t object.
I have a attached a patch to this jira which stops the ConnectionContext::detach method from trying to do remote actions if not connected. The row numbers in this patch assumes that the patch in
QPID-7051 is already applied, which might cause some offset warnings when applying this patch.