double free or corruption (!prev) bug #26
Comments
I'm afraid you'll have to "bisect" the list, since the crash happens in processing, which is triggered for more than one query at once. |
|
Ok, will report back! Thanks. |
|
I'm having trouble. I get to a super small list of domains. It crashes as expected. Then I double check before I post list here--and it doesn't crash on that list anymore. Is it possible pycares is 'caching' the results of the domain or something? Also if its not super important to narrow it down to one single domain, I can just post the list of domains that it definitely crashes on. [edit] but can definitely find a domain, or small list of domains [ie not being lazy]. just not sure if above is an issue. before I query pycares, did a test on 'all.txt' domains, added domains to a 'tried.txt' before query, and after response a 'successful.txt'. but when I double check that set of domains (when it crashes), it no longer crashes for that set. |
|
Nope, there is no caching. If you run the script multiple times, does it
|
|
When I get it narrowed down to like 8 domains. It will crash ~2 times, and then when I run it a third time, it won't (for that set of domains). And I'm trying to narrow down that small set (by re-running), so I can get a specific domain that it happens on.. |
|
Doh. Can you send me the list of domains and the test program? (feel free to email if you don't want to post it here) |
|
So I'm working on putting together a self contained example.. It's not crashing when I don't have my custom client do something on the pycares callback. (i.e. only resolve mx records) I'll figure it out. May have to email you some parts of it. [edit].. Yea.. it's definitely something with combining my client and with the pycares callback. By itself, pycares runs fine. And it also runs fine if I don't use pycurl.PROXY options. It's gonna take me a bit to put together something that you can actually reproduce on your end. |
|
Have done more testing inside of gdb, see this on every crash thus far: |
|
this backtrace is from the longest runinng instance I've had my client going (by disabling most libcurl verification SSL things):
is above helpful at all? is it related to pyuv @ all or libcurl? |
|
The crash happens in a call to libcurl. I suggest you simplify your script to the bare minimum, and add compnents until it blows up, otherwise it's going to be tricky to narrow it down. |
|
ugh, sorry for all my posts. I think that its one thing, then I test more to try and confirm, and it ends up not holding true. I'm almost certain (maybe 80%), that the issue is with my client trying to re-use connections (i.e. it does not hard crash if pycurl.FRESH_CONNECT, 1). If this assumption is valid, do you have any insight as to if the problem be with my client implementation, or a bug with libuv or libcurl? Or, suggestions where to look now? Since it does not hard crash with pycurl.FRESH_CONNECT, I believe I'm at a tipping point of where the problem lies. |
|
It's very hard to tell. The issue you initially opened was a crash in c-ares, maybe because you called some function which is not allowed to run in a callback, like changing the nameservers. Now you get a crash in libgnutls, ... I suggest you start replacing the components until you find the culprit. I know it's hard, but without a reliable way of reproducing the issue I can't really tell if there is a bug and in which library :-) |
|
sending you an email now. will include a zip file with the files, and also made you can account on my server, so you can just log in and run it (if you prefer). If you go that route, and need me to install anything as root, let me know! so much appreciate your help. |
|
The IP/port combo in the code that I gave you is no longer valid. If you are OK w/using the account I created on my server, I'll make sure it always has one that crashes.. |
|
Will do, but it'll take me a few days to find the time. |
|
Just curious, got your response in email. From your experience debugging things.. Is it possible (or likely?) that the issue I originally posted in the pyuv repository, and the backtrace from the program you ran on the server, are the same 'root' bug? Originally in that thread you said that you thought that it might be because of the way pycares was parsing the response.. Then as I removed components, pycares wasn't even a factor.. I guess I'm asking because I wonder that if I'm able to find someone to track down this bug, if it will resolve this hard crash, or if I'm just in a giant rat's nest. in case this is helpful to anyone in the future, this is that backtrace:
|
|
I don't think tehy are related. The first thing I'd recommend is that you install the -dbg versions ob gnutls and curl, so the backtrace has actual symbols, instead of the ??, and start from there. |
|
I will get an example if they are not related. |
|
No follow-up, closing. If you manage to reliably reproduce it, holler and I'll reopen. |
Created by request from saghul/pyuv#214.
To your question in that thread:
Is there a way that I can figure out the domain that crashes it...besides just systematically narrowing down the domains that don't?
Right now I'm just processing a large list of email addresses for many different domains.
The text was updated successfully, but these errors were encountered: