The issue is solved.

With the specification of the writeheader (with headerfunction unset),
when reading headers, the writefunction was used with the writeheader as
userdata, not writedata.
On 1/13/14 3:37 PM, Dan Fandrich wrote:
> 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.
>>
>> http://paste.lisp.org/display/140893
>>
>> 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: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html

-- 
Joshua Kordani
LSA Autonomy

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-01-13