cURL / Mailing Lists / curl-library / Single Mail


Re: curlopts_writedata not being passed to writefunction properly.

From: Dan Fandrich <>
Date: Mon, 13 Jan 2014 21:37:07 +0100

On Mon, Jan 13, 2014 at 11:21:41AM -0500, Joshua Kordani wrote:
> This was originally posted to the curl-users group, and I was encouraged to
> post here instead.
> annotation 1 is a single code file listing that should compile, (you just need
> to link curl)
> annotation 2 is the output I get of running that code on a test rtsp url
> I am running on osx 10.7.5 with the latest curl from macports.
> I am attempting to use writedata and writefunc to parse a response header from
> the server and hand it back out to my application. I've been attempting to
> debug this for a few days. It seems to me that the pointer that gets given to
> the curl library doesn't make its way to the writefunction. I print out the
> value of the pointer before I pass it to curl, and in my test function I print
> out the value of the userdata pointer, and they don't agree.
> In an effort to clarify, I declare a pointer to a struct, initialize it with
> new, and pass it to the curl_writedata function. Some of my printfs aren't
> updated to reflect that, earlier in troubleshooting I'd declared a local struct
> and passed its address instead. I encountered the same problem.
> I have 2 helper macros in there to catch any error as a result of failed calls
> to curl_easy* functions. I have a test struct I use to pass data in and out of
> the writefunc, but the writefunc is just a stub for now, outlining what I'm
> trying to do to access userdata.
> Thanks for any assistance with this.

I didn't spot anything obviously out of the ordinary with the way those curl
options were set up. There's a bug while creating url though--strlen() is being
called on an uninitialized array. And there's an edge condition whereby url
could end up being non-NUL terminated. That could cause a heap overflow when
uri is populated, after which all bets are off.

If you still have the problem once fixing that, can you correlate the pointer
value you see printed in the callback with anything else? Could it be equal to
the stdout handle, for example? Can you try paring down the setopt calls even
further & see if it makes any difference?

>>> Dan
List admin:
Received on 2014-01-13