-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash while resolving a hostname #365
Comments
What pipeline was it on? |
@Asparagirl Pipeline b77f66d2bba045105106122324b1b164 |
Cadbury gave me the database of this job. Let me know if you want it (141 MiB compressed). I don't see anything suspicious in there:
The pipeline uses Google DNS (8.8.4.4 and 8.8.8.8), by the way. |
ArchiveBot job 5e1ikgmizt88z0z4m5n1w7d8r crashed today (I think) on the same pipeline with the identical stack trace. Here's the queue from around the crash (same command as the previous comment; thanks, Cadbury):
Again, this doesn't look suspicious to me. Certainly not a malformed URL or a particular broken host. |
Just happened again this week on one of my pipelines (which have their own resolver, i.e. query the authorative DNS servers) on job |
After we had several of these crashes on Cadbury's pipeline in the past few days, I just looked at the source code a bit to try and figure out what's going wrong. Well, I don't have the slightest clue. The crash occurs while dnspython is trying to determine whether the nameserver IP is a multicast address. dnspython reads a list of nameservers from Then I looked at the lower level, specifically Anyway, I feel like we need to capture the I also found an issue on the dnspython repository with the same traceback: rthalley/dnspython#302 . Unfortunately, the reporter there had the same experience as we do – the issue isn't reproducible. (NB, another issue on that repository, rthalley/dnspython#235, is unrelated. Note that the traceback includes |
I've looked into this again. Specifically, I hammered It didn't take long for that script to crash with the same error. However, the output doesn't look suspicious at all:
This at least confirms that the I then realised that I then had a look at It seems that this issue has been fixed since on the master branch of dnspython. The current implementation of |
Here's a script to test whether dnspython handles such packets correctly. Since it patches some internal methods of |
This should be fixed with dnspython version 1.16.0, but I haven't verified that yet. |
Earlier today, an ArchiveBot job of mine (ID bsrj06s1dk5fv0nepd9ke1clw) crashed in the DNS handling with the following stacktrace:
Unfortunately, I don't know the exact domain name or other circumstances which caused this crash as ArchiveBot's dashboard isn't exactly verbose. Perhaps the person running the corresponding pipeline could provide more details.
The text was updated successfully, but these errors were encountered: