http://bugzilla.spamassassin.org/show_bug.cgi?id=3924
------- Additional Comments From [EMAIL PROTECTED] 2004-10-27 10:45 ------- I've done some more tests, but haven't nailed this yet. I determined that it is not a matter of running out of file handles (descriptors). It does feel like some buffer deep inside is filling up. The crash happens consistently in the same place on the same data between runs. There are about 450 sockets fired off, half of them of type DNSBL and half NS. The first to be ready to be read is a DNSBL. The next one, which crashes in of type NS. The crash happens when there is a call to bgisready (a sub in Net::DNS). All that sub does is create a new IO::Select from its IO::Socket argument and call IO::Select->can_read() on it. When I substitute those calls the crash still happens. This seems to place the problem in IO::Socket or IO::Select, unless there is something that Net::DNS can do differently to avoid whatever is going on. I tried looking at the socket object that crashes but don't see anything obvious that indicates that it is bad. Of the four blocks of urirhssbl and uridnsbl added to the preferences, the crash happens if the third one and any one other is inthere, or if just the thir one is removed. That makes it seem like it is quantity, not a specific entry, that is making the difference. This needs more digging, but is quite reproducable and is a critical error for running on the Windows platform. I'm about to go back behind that firewall and will have to stop testing for another day. ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.
