Culprit tracked...

Curl::easy sets up an internal WRITEHEADERFUNCTION and WRITEFUNCTION
(replacing the fwrite default) to catch all write callbacks, and then
tries to decide if the output should go through a perl GLOB file
descriptor, a stdio descriptor or a perl subroutine callback (SV *)
based on the stream pointer value.

Michael's script didn't set up its own WRITEHEADER file, but the test.pl
with Curl::easy does, so test.pl works, but Michael's segfaults...

This change in 7.8.1:

----
Revision 1.25 / (download) / (as text) - annotate - [select for diffs] ,
Mon Aug 6 08:22:26 2001 UTC (4 weeks, 6 days ago) by bagder 
Branch: MAIN 
CVS Tags: curl-7_8_1-pre3 
Changes since 1.24: +3 -2 lines 
Diff to previous 1.24 to selected 1.27 
  Jonathan Hseu noticed that you couldn't get a header callback unless
you
  set CURLOPT_WRITEHEADER to non-NULL, even if you didn't care about
that
  data. This is now fixed.
----
means that WRITEHEADERFUNCTION can get called even when WRITEHEADER is
NULL (no header output stream is defined), which is what was happening.
This was previously impossible. Curl::easy received a stream pointer of
NULL, null != stdout and null != (address of Curl::easy internal
callback function), so it must be a pointer to a perl GLOB, which we try
to turn back into an STDIO stream using
f = IoIFP(sv_2io(stream));
stream == NULL, so this faults.
Initially, the prototype signature of a curl IO callback was (by
definition) the same prototype as that of fwrite/fread, with stream of
type (FILE *). The callbacks are now more widely interpreted with stream
of type (void *), so I suppose its now legal for stream to be NULL. The
default curl callback, fwrite, segfaults if given a NULL stream, so I'm
sure the change may cause other applications which define
WRITEHEADERFUNCTION to fault if they expect stream != NULL. As
WRITEHEADERFUNCTION is only since 7.7.2, its probably not widespread.
I'll whip up a patch for Curl::easy to discard the header data if stream
== NULL, and check it in, if thats OK with you Daniel - I'd like to
extend the test harness and do other Curl::easy work previously
discussed, but I don't have time just now....
Cris
Daniel Stenberg wrote:
> 
> On Fri, 7 Sep 2001, Michael S. Steuer wrote:
> 
> > I used libcurl 7.8.*, with your version it works too. Guess 7.8 isn't as
> > stable...
> 
> I wouldn't put it that boldly. I'd say that things have changed since 7.7.2,
> and that the perl interface may not be playing along properly. Perhaps
> there's a newly introduced bug that causes this, but 7.8.1 is actually the
> best and most stable release of (lib)curl so far. IMHO.
> 
> It's been downloaded an estimated 20,000 times (counted low) and besides the
> configure messup, there has been very few bug reports.
> 
> --
>     Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/