cURL Mailing List Monthly Index Single Mail
curlopt_writefunction on error
From: Andy Shellam (Mailing Lists) <andy-lists_at_networkmail.eu>
Date: Mon, 16 Nov 2009 12:38:17 +0000
I've got a weird problem using a function passed to curlopt_writefunction, using cURL library (easy interface) version 7.19.7 on a Redhat EL 5.4 system.
I'm using libcurl as part of a C++ application to send/receive checkout requests and notifications to Google Checkout. I've got this working perfectly on the same system talking to a different server in a different application, and as far as I can tell the code is virtually identical so I'm not sure where it's going wrong.
In the working application, cURL passes 1 as the size parameter and the number of characters (e.g. 16,384 = 16K) as the nmemb parameter to my write function. But, in the new one that doesn't work, I'm getting huge size and nmemb parameters that are causing the application to try and allocate 3GB of memory!
Here's a GDB output at the point my write function is called:
Breakpoint 1, aspire_platform::GoogleCheckoutClient::OnDataRead (
Notice that the pointer to the data (ptr) has the address of 0x1 which causes a segfault if I try to read it:
(gdb) p (char*)ptr
Also the "307" passed to the size parameter is actually the size of the data received - no idea what the nmemb figure is. In my working application, the size of the data is in the nmemb parameter, and the size parameter is always 1.
Any ideas what could cause this? Note that the working application does typically have 2-3 calls made to my write function (it receives an average of 25KB) whereas this one has tiny responses (average of 300 bytes) - is that significant?
This is a GDB trace of the same point in the working application:
Breakpoint 1, aspire_platform::OpenSrsClient::OnDataRead (ptr=0x8a6b1cc,
Both cURL sessions are set up the same - they both POST some XML data to the remote server, and both servers return HTTP status 200. Also I've just noticed that the working version has a "stream" pointer passed to it, but the non-working one doesn't - yet neither sets the option curlopt_writedata.
These mail archives are generated by hypermail.
Page updated November 16, 2009.
web site info