hi there, folks:
I'd really like to release 0.7.0 but I would like it to be at least a
little bit tested before I do so. Could those of you with CVS trees check
everything out and see if it performs as advertised? Deeper bugs than
that will have to wait for the next release, but I'd at least like to know
if it works for someone other than me.
______ __ __ _____ _ _
| ____ | \_/ |_____] |_____|
|_____| |_____ | | | |
@ t w i s t e d m a t r i x . c o m
I'm getting a "maximum recursion depth exceeded" error that appears to be coming from flatten(). The odd thing is that it only happens sometimes. The HTML that's being flattened does have a few Deferreds in it. Those come from function calls, which cache the results, which might explain why I only see the error on the first visit to the page (as far as I can tell).
The system recursion limit is the standard 1000. My HTML is only nested a few tags deep, two orders of magnitude short of that. Is there anything about the way flatten() works that might cause this behaviour?
TLDR: Twisted appears broken on PyPy 7.3.4 (aka "3.7.10")?
I don't have time right now to set up a PyPy-capable environment and try
to reproduce this, but perhaps someone does?
Trunk has been broken since the last merge a week or so ago, but I
don't think the breakage is due to that merge. As an experiment I made
a PR based off the last successful version of trunk, with a whitespace
change, and it now fails CI as well. So I think the failure must be due
to some change that isn't in Twisted or controlled-for by tox.
The failure in all cases is in the pypy-3.7-alldeps-nocov-posix task.
Unlike our usual CI problems it doesn't seem to be a random failure: it
fails all the time in the same place. But the place doesn't make sense
to me. It's in the IRC CTCP tests, and they fail in the same ways each
time (an expected response is not received).
The pair of CI runs closest to the change are these:
run 5793: https://github.com/twisted/twisted/runs/2328450554
run 5809: https://github.com/twisted/twisted/runs/2360415474
There are a lot of differences, but sys.version went from 3.7.9 to
3.7.10 between those runs, so that seems like the most likely culprit.
> sys.version : 3.7.9 (7e6e2bb30ac5, Nov 18 2020, 10:55:52)
> [PyPy 7.3.3-beta0 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
> sys.prefix : /opt/hostedtoolcache/PyPy/3.7.9/x64
> sys.exec_prefix : /opt/hostedtoolcache/PyPy/3.7.9/x64
> sys.executable : /opt/hostedtoolcache/PyPy/3.7.9/x64/bin/python
> sys.version : 3.7.10 (51efa818fd9b, Apr 04 2021, 11:22:34)
> [PyPy 7.3.4 with GCC 7.3.1 20180303 (Red Hat 7.3.1-5)]
> sys.prefix : /opt/hostedtoolcache/PyPy/3.7.10/x64
> sys.exec_prefix : /opt/hostedtoolcache/PyPy/3.7.10/x64
> sys.executable : /opt/hostedtoolcache/PyPy/3.7.10/x64/bin/python
PyPy's release notes for 7.3.4 don't list anything that jumps out at me:
My guess would be some latent timing bug in Twisted that was uncovered
by pypy execution time changes (I don't imagine that the CTCP code gets
exercised very heavily these days) or perhaps PyPy got a bug.
I am working on twisted names since some days to make kind of filtering system (with domains blacklists).
So I made my own resolver that can reply defer.fail(error.DomainError()) to send the query to the next resolver (and in this case, it will be resolve) or defer.fail(dns.AuthoritativeDomainError(query.name.name)) to reply NXDOMAIN that can "block" the domain to the final client.
That part is working well.
Next, i would like to "block" the resolution regarding the device (Mac address/IP/???).
I would like something like that :
if self.query.meta.client.ip == b"192.168.0.5" or self.query.meta.client.mac == "XX:YY:ZZ:....":
My use case is that device of Kelly, (Kelly is a teenager of 12 years) cant use youtube.com at all, but other devices are allowed to get the resolution.
How can I get the IP/Name/mac (an identifier) of the device that's querying my custom dns?
I read something about datagrams, but in my case i think i must get this information in my resolver...
Thx and cheers.