BUG: prevent QHull message stream being closed twice

[andfoy]

Reference issue

This makes part of the current effort to remove the GIL from Python. After numpy/numpy#26348 and this PR, all the test suite passes successfully when ran locally.

What does this implement/fix?

This PR prevents releasing the MessageStream object in QHull twice. This may occur because the deallocation logic is duplicated both in the close and the __dealloc__ methods (there's a note mentioning that this is required to support PyPy). Before, a call to close followed by __dealloc__ would segfault, since close would have closed the MessageStream before __dealloc__ would have attempted to close it, thus trying to free a null pointer.

Additional information

This behaviour occurs independent of locking, since the closing attempt would have occurred without checking if self._qh != NULL

[rgommers]

Thanks @andfoy. I don't think this fix is quite correct. self._messages is a separate object from self._qh, and can be non-null even if _qh is null. The logic in __init__ is:

        self._qh = NULL
        self._messages = MessageStream()
        # now do a bunch of things, including validation steps that can raise exceptions
        self._qh = malloc(...)

So this change would leave the instantiated MessageStream open in case an exception is raised before _qh is allocated, leaking the memory stream or file handle.

MessageStream.close actually looks safe to call multiple times. Is the problem you are seeing calling it twice and something inside the state of the MessageStream object not existing anymore, or is it that inside _Qhull self._messages itself no longer exists?

[andfoy]

Thanks for bringing these points up @rgommers, now that you mentioned it, the MessageStream object pointer is being set to NULL at some point, which I found to be correlated to not be NULL when _qh is still valid.

I'll add a self._messages != NULL check then.

[rgommers]

Thanks! LGTM now.