On Fri, 20 Apr 2001, Gabriel Ambuehl wrote:

> If I haven't completely misunderstood the concept of the threading lib,
> I'd say I do so as I do curl=curl_easy_init() in the constructor of the
> class (which works, BTW). IMHO this should yield a completely independent
> curl ptr (as the counters definitely are independent, i.e. they don't
> increment if not told to do so in the same thread). The other member
> variables of the class are also separate as a dump_config statement will
> yield the different configs if the program is told to use them.

So, would you be capable of following (single-steppping) the second thread
into the curl_easy_perform() call?

What if you create a few threads first _without_ calling curl_easy_perform()
and then call it on the second or third thread? If this is a libcurl bug, it
really should work then. If it doesn't, the problem is not in curl.

> > Can you show us a stack trace?
>
> Sure. gdb bt yields the following:
>
> [regular output]
> Fatal error '_waitq_remove: Not in queue' at line ? in file
> /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = ?)
> (no debugging symbols found)...(no debugging symbols found)...
> Program received signal SIGABRT, Aborted.
> 0x282b58dc in kill () from /usr/lib/libc_r.so.4
> (gdb) bt
> #0 0x282b58dc in kill () from /usr/lib/libc_r.so.4
> #1 0x282ffdbe in abort () from /usr/lib/libc_r.so.4
> #2 0x282cc789 in _thread_exit () from /usr/lib/libc_r.so.4
> #3 0x282c61be in _waitq_remove () from /usr/lib/libc_r.so.4
> #4 0x282c81fd in _thread_kern_scheduler () from /usr/lib/libc_r.so.4
> #5 0x0 in ?? ()

Hm, can this be an abort() or signal problem? Although libcurl should not
mess with any signals unless you specify a timeout.

Do you know what in libcurl that causes this? I mean, like what function call
or about which function in the lib?

> I've there got another oddity when the lib is called from C++: half the
> request (the even ones, IIRC) generated are completely broken as the
> apache_error_log shows the following: [Thu Apr 19 19:29:28 2001] [error]
> [client 10.2.2.70] Invalid URI in request GET ÿÿÿÿ HTTP/1.1 then correct
> and malformed requests are alternating (broken ones are always the same).

That might be because you pass a char pointer to libcurl that you free or
reuse before libcurl is done. You must make sure they remain present until
libcurl is done using them.

> Hmm. I tryed to recompile libcurl with -pthread -D_THREAD_SAFE but it
> didn't help.

The main configure script already attempts to detect thread-safe versions of
all libc/resolve functions in use that need such.

> The strange thing is: from C, CURLOPT_MUTE works without any problems. -
> From C++, it is ignored. The progress meter stuff, OTOH, gets deactivated
> like it should.

Somehow, I don't think libcurl behaves differently depending on your language
of choice, but I figure the use of the lib differs...

> Never done any Python wrappers before but...

Me neither, but that's one the remaining major languages that unfortunately
still lacks a libcurl interface.

-- 
  Daniel Stenberg -- curl project maintainer -- http://curl.haxx.se/
_______________________________________________
Curl-library mailing list
Curl-library_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-library