cURL / Mailing Lists / curl-library / Single Mail

curl-library

RE: Windows RPC server busy. Libcurl Multithreading issues.

From: Jim N <jim_at_bluedojo.com>
Date: Tue, 18 Jan 2005 21:33:22 -0800 (PST)

Here's an update on the RPC server busy. If anyone is out there still
listening here it is.

1) The good news: I FINALLY got it to compile with c-ares in Windows. The
biggest problem I had in doing this was that c-ares 1.2.1 downloaded at
http://daniel.haxx.se/projects/c-ares/ did not work. I had to get it out
of CVS to make it compile with libcurl correctly. Big sigh...

2) More good news: No more RPC Exception!

3) The bad news: Even though I compiled it with c-ares, I STILL get
another exception to come up: "Access violation reading location
0x2e77777b". It only comes up after running a while with multiple
threads. This totally crashes the program. Curl is easy to use but
multithreading makes it so hard.

Here is the Stack for the Access Violation:

> libcurl.dll!addrinfo_callback(void * arg=0x02a5c3c0, int status=0, void
* addr=0x00d26290) Line 132 + 0x3 C
libcurl.dll!Curl_addrinfo4_callback(void * arg=0x02a5c3c0, int status=0,
hostent * hostent=0x00d26290) Line 162 + 0x11 C
libcurl.dll!end_hquery(host_query * hquery=0x00cd4c00, int status=0,
hostent * host=0x00d26290) Line 155 + 0x17 C
libcurl.dll!host_callback(void * arg=0x00cd4c00, int status=0, unsigned
char * abuf=0x012ab54c, int alen=93) Line 144 + 0x11 C
libcurl.dll!qcallback(void * arg=0x003dcc68, int status=0, unsigned char *
abuf=0x012ab54c, int alen=93) Line 108 + 0x1a C
libcurl.dll!end_query(ares_channeldata * channel=0x003dba50, query *
query=0x003dccb0, int status=0, unsigned char * abuf=0x012ab54c, int
alen=93) Line 627 + 0x1b C
libcurl.dll!process_answer(ares_channeldata * channel=0x003dba50, unsigned
char * abuf=0x012ab54c, int alen=93, int whichserver=0, int tcp=0, int
now=1106112375) Line 359 + 0x17 C
libcurl.dll!read_udp_packets(ares_channeldata * channel=0x003dba50, fd_set
* read_fds=0x012ab9d0, long now=1106112375) Line 273 + 0x1e C
libcurl.dll!ares_process(ares_channeldata * channel=0x003dba50, fd_set *
read_fds=0x012ab9d0, fd_set * write_fds=0x012ab8c4) Line 78 + 0x11 C
libcurl.dll!Curl_wait_for_resolv(connectdata * conn=0x02a5c3c0,
Curl_dns_entry * * entry=0x00000000) Line 219 + 0x1d C
libcurl.dll!Curl_connect_host(SessionHandle * data=0x00c693f0, connectdata
* * conn=0x012abb3c) Line 2050 + 0xd C
libcurl.dll!Curl_perform(SessionHandle * data=0x00c693f0) Line 2104 + 0xd C
libcurl.dll!curl_easy_perform(void * curl=0x00c693f0) Line 389 + 0x9 C
GetRobots.exe!SpiderProc(char * MyID=0x004189e8) Line 310 + 0xc C
msvcr71d.dll!_threadstart(void * ptd=0x003e5e98) Line 196 + 0xd C

The error occurs in "hostasyn.c" at line number 132 in function
"addrinfo_callback()".

I don't mean to send out all these emails but maybe it will give someone,
anyone an idea on compiling multithreaded curl application.

> Daniel,
>
>> The debugger shows some error in some heap allocation/deallocation
>> routine.
>
> You said:
>
> Do you happen to have any more details?
>
> Well, I've isolated the file and the error. The error occurs in file
> "dbgheap.c" on line 448 (See below):
>
> memset((void *)pbData(pHead), _bCleanLandFill, nSize);
>
> Here is a copy of the stack:
>
>> msvcr71d.dll!_heap_alloc_dbg(unsigned int nSize=2012580337, int
> nBlockUse=1310720, const char * szFileName=0x40000060, int
> nLine=2012581569) Line 448 + 0x18 C
> ntdll.dll!77f84cd3()
> mswsock.dll!71a5398b()
> .
> .
> .
> kernel32.dll!77e79d58()
> libcurl.dll!_CrtIsValidHeapPointer(const void * pUserData=0x0034799b)
> Line 1807 C
> kernel32.dll!77e79d58()
> libcurl.dll!gethostbyname_thread(void * arg=0x003df198) Line 203 + 0x12 C
> libcurl.dll!_threadstartex(void * ptd=0x003dfd80) Line 241 + 0xd C
> kernel32.dll!77e802ed()
> ntdll.dll!77f588ad()
>
> I used the latest version of curl-7.12.3. Compiled it normally with VC in
> Debug mode. Then used the libcurl in my multi-threaded program. If one
> thread is used works great. But at 50 threads it causes an exception
> every second or so.
>
>
>> I'm trying out some of your suggestions and I've download libcurl 7.12.3
>> and built it in VC. I didn't use Ares as an option yet (since Gisle
>> mentioned it should me working since 7.12.2)
>>
>> It still causes an exception in the file "hostthre.c" at line 189 in the
>> function "gethostbyname_thread()" See below:
>>
>> static unsigned __stdcall gethostbyname_thread (void *arg)
>> {
>> struct connectdata *conn = (struct connectdata*) arg;
>> struct thread_data *td = (struct thread_data*)
>> conn->async.os_specific;
>> struct hostent *he;
>> int rc = 0;
>>
>> /* Duplicate the passed mutex handle.
>> * This allows us to use it even after the container gets destroyed
>> * due to a resolver timeout.
>> */
>> HANDLE mutex_waiting = NULL;
>> if (!DuplicateHandle(GetCurrentProcess(), td->mutex_waiting,
>> GetCurrentProcess(), &mutex_waiting, 0, FALSE,
>> DUPLICATE_SAME_ACCESS)) {
>> //**************
>> EXCEPTION OCCURS HERE!
>> "First-chance exception at 0x77e6d756 in Program.exe: 0x000006BB: The
>> RPC
>> server is too busy to complete this operation."
>> *****************//
>> /* failed to duplicate the mutex, no point in continuing */
>> return 0;
>> }
>>
>>
>> I am going to try and use Ares tonite if I have time. I am actually on
>> lunch break at home working on this since this is not a work related
>> project. I'm new to this email list so hopefully this email works
>> correctly, since I've had a little trouble emailing to the list.
>>
>> Thanks.
>>
>>> As I said, my test program works just fine with a standard windows
>>> build
>>> Of 7.12.3, so I think it was fixed :)
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: curl-library-bounces_at_cool.haxx.se
>>> [mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Gisle Vanem
>>> Sent: Tuesday, January 18, 2005 8:54 AM
>>> To: libcurl development
>>> Subject: Re: Windows RPC server busy. Libcurl Multithreading issues.
>>>
>>> "Michael Mastroianni" wrote:
>>>
>>>> With 7.12.0, not using Ares, it would blow up every time.
>>>
>>> The threaded resolver code was hopefully fixed in 7.12.2 by
>>> Traian Nicolescu's patches.
>>>
>>> --gv
>>>
>>
>
Received on 2005-01-19