Hello curl list,

I just wanted to let everyone to know I was able to figure out how to run
libcurl, multithreaded, in Windows. Thanks to Michael, Daniel and, Gisle.

First off you have to compile libcurl using c-ares. One of the main
problems I had with this was I had to compile the program using
Multithreaded (MT) for c-ares, libcurl, and my program. In the
instructions located in /curl/lib/README.ares in the Windows section it
says to compile it using single threaded due to linking errors. Well,
compiling it in single threaded will only causes access violations later
on. I was able to compile it using Multithreaded (MT) with no problems.

I am very happy it is working.

Jim

> Not a problem...
>
> I think I agree with you...there must be a memory leak in my code. :)
>
> Jim
>
>> Sorry, I forgot to send you my test program last night. I'll do it
>> today.
>>
>> It's a little tricky to get curl working in threads, but other than the
>> name resolution bug, every thread-related crash I've experienced using
>> it has been due to bugs in my code.
>>
>>
>>
>> -----Original Message-----
>> From: curl-library-bounces_at_cool.haxx.se
>> [mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Jim N
>> Sent: Wednesday, January 19, 2005 12:33 AM
>> To: libcurl development
>> Subject: RE: Windows RPC server busy. Libcurl Multithreading issues.
>>
>> 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-25