Haxx ad

Shopping cart software, Online file storage, Online photo storage, Hosted shopping cart, Contact management software, Email marketing software, Project management software, Issue tracking software, Online notepad, Web publishing software

curl's project page on


cURL > Mailing List > Monthly Index > Single Mail

curl-library Archives

curlopt_writefunction on error

From: Andy Shellam (Mailing Lists) <>
Date: Mon, 16 Nov 2009 12:38:17 +0000

Hi all,

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 (
    this=0x80ee011, ptr=0x1, size=307, nmemb=11936960, stream=0x0)
    at /opt/nmail32/aspire_backend/google_lib/src/GoogleCheckoutClient.cpp:236

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
$1 = 0x1 <Address 0x1 out of bounds>

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,
    size=1, nmemb=423, stream=0xb624c0)
    at /opt/nmail32/aspire_backend/opensrs_lib/src/OpenSrsClient.cpp:299
(gdb) p (char*)ptr
$3 = 0x8a6b1cc "<?xml version='1.0' encoding=\"UTF-8\" standalone=\"no\" ?>\n..."

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.

Many thanks,
List admin:
Received on 2009-11-16

These mail archives are generated by hypermail.

donate! Page updated November 16, 2009.
web site info

File upload with ASP.NET