You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
socket.close() doesn't play well with __del__ #39247
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
assignee=Noneclosed_at=<Date2010-08-31.21:21:22.596>created_at=<Date2003-09-17.21:16:55.000>labels= ['extension-modules', 'type-bug']
title="socket.close() doesn't play well with __del__"updated_at=<Date2010-08-31.21:21:22.592>user='https://bugs.python.org/perrygreenfield'
It appears that 2.3 changed how socket.close() works.
We now find errors when terminating Python when we
reference socket.close() in a __del__ method. We have
worked around it by removing calls to socket.close() but
note the following differences between the same section
of code between 2.2 and 2.3 which suggest that the 2.3
behavior is not ideal and should be fixed.
Note the reference to avoiding globals which is
presumably the source of the problem with 2.3. Perhaps
I'm naive but I would guess that calling a close method
should be considered a safe operation for use in a
__del__ method.
Two other comments on socket.close() in Python 2.3.
In addition, the socket.close() method in the Lib/socket.py
class does not even call the _realsocket.close() method.
Before zapping the _sock attribute, shouldn't the latter
close() method be called first? If not, what happens to
any data which may be buffered by the _realsocket?
Also, every time the socket.close() method is called
another, new instance of the _closedsocket class is
created. That seems unnecessary waste.
Why not use a single instance created once at the
module level?
Well, realistically, if you have open sockets at shutdown, there isn't a big difference between closing and not closing them. They will be reaped with the process anyway.
stutzbach commented on Apr 28, 2010
stutzbachmannequin
Mannequin
More actions
The purpose of calling .close() in __del__ is to close the socket when the owner is destroyed yet the program is still running.
This prevents the socket from staying open if some other part of the program has somehow acquired a reference to it. telnetlib, urllib, and even the socket module itself contain classes that call .close() within __del__ for this purpose.
Unfortunately, that can result in ugly error messages when the interpreter is exiting.
How do I write a unit test to check that socket.__del__ doesn't refer to any globals?
BreamoreBoy commented on Aug 18, 2010
BreamoreBoymannequin
Mannequin
More actions
Can someone reply to Daniel Stutzbach's query in msg104541, thanks.
stutzbach commented on Aug 18, 2010
stutzbachmannequin
Mannequin
More actions
I suspect that it's not possible.
I'm uploading patches that fix the .close method to avoid referencing globals that might be None during interpreter shutdown. Since the .close method has changed significantly in py3k, I'm uploading separate patches for py3k and 2.7.
Activity
perrygreenfield commentedon Sep 17, 2003
It appears that 2.3 changed how socket.close() works.
We now find errors when terminating Python when we
reference socket.close() in a __del__ method. We have
worked around it by removing calls to socket.close() but
note the following differences between the same section
of code between 2.2 and 2.3 which suggest that the 2.3
behavior is not ideal and should be fixed.
In Python 2.3:
In Python 2.2:
Note the reference to avoiding globals which is
presumably the source of the problem with 2.3. Perhaps
I'm naive but I would guess that calling a close method
should be considered a safe operation for use in a
__del__ method.
jbrouwers commentedon Feb 25, 2004
Logged In: YES
user_id=832557
Two other comments on socket.close() in Python 2.3.
In addition, the socket.close() method in the Lib/socket.py
class does not even call the _realsocket.close() method.
Before zapping the _sock attribute, shouldn't the latter
close() method be called first? If not, what happens to
any data which may be buffered by the _realsocket?
Also, every time the socket.close() method is called
another, new instance of the _closedsocket class is
created. That seems unnecessary waste.
Why not use a single instance created once at the
module level?
devdanzin commentedon Feb 14, 2009
Current code is:
It sure seems to be trying to avoid __del__ issues, does it fix this bug?
stutzbach commentedon Mar 31, 2009
Daniel,
_closedsocket is a global, so it isn't safe to be used within __del__
during shutdown.
In the py3k branch, socket.__del__ calls socket._real_close which
references the global _socket. So it's not safe their, either.
isterika commentedon May 17, 2009
The same is happened when you are trying to close pycurl handler at
__del__ method.
pitrou commentedon Apr 27, 2010
Well, realistically, if you have open sockets at shutdown, there isn't a big difference between closing and not closing them. They will be reaped with the process anyway.
stutzbach commentedon Apr 28, 2010
The purpose of calling .close() in __del__ is to close the socket when the owner is destroyed yet the program is still running.
This prevents the socket from staying open if some other part of the program has somehow acquired a reference to it. telnetlib, urllib, and even the socket module itself contain classes that call .close() within __del__ for this purpose.
Unfortunately, that can result in ugly error messages when the interpreter is exiting.
pitrou commentedon Apr 28, 2010
The classical solution is to early bind the necessary globals to
argument defaults, such as:
stutzbach commentedon Apr 29, 2010
How do I write a unit test to check that socket.__del__ doesn't refer to any globals?
BreamoreBoy commentedon Aug 18, 2010
Can someone reply to Daniel Stutzbach's query in msg104541, thanks.
stutzbach commentedon Aug 18, 2010
I suspect that it's not possible.
I'm uploading patches that fix the .close method to avoid referencing globals that might be None during interpreter shutdown. Since the .close method has changed significantly in py3k, I'm uploading separate patches for py3k and 2.7.
stutzbach commentedon Aug 18, 2010
Here is the py3k version of the patch
stutzbach commentedon Aug 31, 2010
Fixed in r84380 and r84382.