LibCurl version: 7.12.1

Okay, it's a little complicated but I'll do my best to describe the
problem. Maybe it leads to some suggestions...

My application downlaods data using libcurl from an ISAPI DLL on an IIS
server all done on port 80. No proxy servers and using a direct
conection. I have several servers on totally different networks and have
verified that a single server is not to blame...happens on all of them.

I had a few customers getting problems and I've tracked it down to kerio
personal firewall. Maybe other such products do the same but I can
reproduce it with kerio.

The firewall blocks one or more transfers claiming the exploit below was
the reason:
  -->http://www.securityfocus.com/bid/4006/info/

I dunno how. My product just uses port 80 to download binary data from
the server. Nothing fancy or exotic. I don't have SQL server installed
either.

It's a very difficult problem to reproduce. I can transfer several
thousand files and not get it, I can then transfer just a few dozen and
it happens. Almost random.

My application has several threads servicing a queue of files to
download. Each thread does curl_easy_init(), curl_easy_perform(...) and
curl_easy_cleanup(...) for each file it processes. The more threads I
have the more likely the problem is to occur apparently.

Curl loops around in Transfer() (Transfer.c)....and never exits. The
result is that my app never completes it's downloads - my only option at
the moment is to detect this and, ugh, TerminateThread (I'm not going to
do this, just saying is all hehe).

The callstack looks like this:
NTDLL! 7c90eb94()
MSWSOCK! 71a55fa7()
WS2_32! 71ab2e67()
Transfer(connectdata * 0x06334028) line 1496 + 38 bytes
Curl_perform(SessionHandle * 0x063abf48) line 2037 + 9 bytes
curl_easy_perform(void * 0x063abf48) line 379 + 9 bytes
CLibCurlInterface::CurlThread(void * 0x015221b8) line 313 + 9 bytes
_threadstart(void * 0x0152b018) line 173 + 13 bytes

Any suggestions as to how I can avoid this problem? Any suggestions as
to how I can go about consistently reproducing the problem so maybe we
can come up with a fix..any help at all (if I sound desperate it's
because I am).

russ.
Received on 2004-11-21