As of iRODS 4.19, any use of iRODS by libmaus2 crashes on program exit. Both iRODS and libmaus2 use statically stored singleton objects that only go out of scope on program exit. As objects are deallocated in reverse order of allocation, the iRODS objects that were created on rcConnect are destroyed before libmaus2 calls rcDisconnect leading to the disconnect code trying to access now invalid memory locations. These changes add an explicit call to disconnect so that it happens before the program ending atexit handlers are called.
As of iRODS 4.19, any use of iRODS by libmaus2 crashes on program exit. Both iRODS and libmaus2 use statically stored singleton objects that only go out of scope on program exit. As objects are deallocated in reverse order of allocation, the iRODS objects that were created on rcConnect are destroyed before libmaus2 calls rcDisconnect leading to the disconnect code trying to access now invalid memory locations. These changes add an explicit call to disconnect so that it happens before the program ending atexit handlers are called.