-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

| Just to make things clear: that will not use pipelining. libcurl does not
| support pipelining. It will use a persistent (if possible) connection
though.

Ahh.. thanks for the clear up. You're right: I meant persistent
connections.

| Are you passing data to the program using stdin and the default read
| functionality? Then this does not suprise me. By default, if you don't set
| your own read callback (which most users of libcurl do) libcurl will
read all
| data from stdin.

Nope, the data that is being posted is a file. In fact, the calls that
set this up are:

~ curl_easy_setopt(curl, CURLOPT_CAINFO, "brivoca.pem");
~ curl_easy_setopt(curl, CURLOPT_USERPWD, strdup(userpw));
~ curl_easy_setopt(curl, CURLOPT_HTTPHEADER, request_headers);
~ curl_easy_setopt(curl, CURLOPT_POST, 1);
~ curl_easy_setopt(curl, CURLOPT_POSTFIELDSIZE, (long)filestats.st_size);
~ curl_easy_setopt(curl, CURLOPT_READDATA, input);
~ curl_easy_setopt(curl, CURLOPT_URL, msg->url);
~ curl_easy_setopt(curl, CURLOPT_HEADERFUNCTION, SaveHeaders);
~ curl_easy_setopt(curl, CURLOPT_WRITEHEADER, (void *)&response_headers);
~ curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, QuietWriter);

According to the docs, and from what I'm seeing, 'input' must be a
FILE*. If so, then the default function to read it in becomes fread.

|
| When no more data comes it will consider the upload done. Of course,
if you
| then initiates a second transfer the stream of data on the stdin has
stopped
| and then libcurl will hang in the fread() waiting for more data to arrive.

Hmm... well, since I'm not using stdin, could it be related. Before the
above curl_easy_setopt calls, I fopen the file. At the end of that, I
fclose it, then unlink it.

All of that, however, is in a function that is called over and over.
Could it be that curl's internal fread (from transfer.c) isn't setting
its counters correctly? It's probably waiting for more data instead of
starting back at the beginning for every call of perform.

| That is puzzling however. Can you figure out more details on why and when
| this happens?
|
| Can you provide us a simple source code example that shows a stand-alone
| program where this happens?

I'll see if I can whittle down the existing code. I would image that
the above code, w/ the fopen and fclose all placed in a loop, then that
loop called quickly would do it. The crash, according to gdb, is from
some internal call of libc (something like __XX_sgetn). Most of the
time, though, the segfault is fread. See previous email with stack trace.

Hope that helps.

Oh, even if I make my own function that I give to CURL_READDATA, I get
same results. This makes sense, though, because my READDATA function
just calls fread exactly how transfer.c does.

Thanks,
Seth

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAj5mDDYACgkQNx3GJTf/82WQEgCeLHtNIv7dOruD1TwdMcYO1qqw
fBMAnRo6tlM1oQbPNyHeDxKdP9rwVAdy
=zDl9
-----END PGP SIGNATURE-----

-------------------------------------------------------
This SF.net email is sponsored by: Etnus, makers of TotalView, The debugger
for complex code. Debugging C/C++ programs can leave you feeling lost and
disoriented. TotalView can help you find your way. Available on major UNIX
and Linux platforms. Try it free. www.etnus.com
Received on 2003-03-05