David Ford (FirefighterBlu3) added the comment:
i quite understand the way objects can be associated with reference counts by
using a, a.b, c=a.b, d=a, etc etc, and how they increase/decrease and when the
GC can prune the objects. yes, the root issue is the unclosed web socket and
i've already filed a bug with Twilio.
@Martin,
/usr/lib/python3.6/site-packages/psycopg2/extras.py:314: ResourceWarning:
unclosed <ssl.SSLSocket fd=10, family=AddressFamily.AF_INET,
type=SocketKind.SOCK_STREAM, proto=6, laddr=('173.12.76.132', 42016),
raddr=('52.7.124.13', 443)>
/usr/lib/python3.6/site-packages/psycopg2/extras.py:314 is unrelated to the
resource in question. there is nothing in psycopg2 that can have any direct or
indirect reference to the tcp/443 socket used by the twilio by any path in the
code all the way back to glibc under python. nothing in psycopg2 and twilio
down to _ssl/glibc have any associated references.
the reference link between the two is at best as vague as connecting the water
in the garden hose to the condensation on the hot shower mirror.
the pg socket is created and used which will fetch a result that has no
reference to the socket used by that query method. regardless, the socket is a
completely different IP/port pair. there is nothing in the pool, connection,
cursor, or query that will ever be used by twilio. psycopg2 has nothing to do
with any of the http or httplib2 modules.
after the pgsql query is completed, the twilio module gets used. a new https
socket is created. the only data every seen by the twilio module that has a
reference to any objected created by the psycopg2 module is the r.delivery_id
which is a UUID value derived from the pgsql database. it has no references to
its parent chain of objects and the twilio module doesn't derive any objects
from it.
to be more obtuse about it, if i replace the r.delivery_id with a quoted string
i manually insert, the ResourceWarning is now logged against asyncio/events.py.
the traceback is still the same.
/usr/lib/python3.6/asyncio/events.py:126: ResourceWarning: unclosed
<ssl.SSLSocket fd=10, family=AddressFamily.AF_INET,
type=SocketKind.SOCK_STREAM, proto=6, laddr=('173.12.76.132', 40668),
raddr=('54.164.135.121', 443)>
self._callback(*self._args)
this one happens to exist in the stack trace albeit even further up the call
chain.
if the ResourceWarning is unable to emit an accurate file:pos, then it
shouldn't print it at all and instead, use the stack print as mentioned by
@STINNER. at least at this point, the developer has a legitimate stack to
wander through and isn't going on a wild goose chase in an unrelated file.
i argue that printing a completely unrelated file:pos is definitely a bug. if
it is likely to emit a wholly unrelated file:pos, it shouldn't be printed at
all. unreliable information is just useless.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29564>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
