That does it. I'm not sure what to do if malloc(newlen) fails though.

Thanks much.

-DB

-----Original Message-----
From: curl-library-bounces_at_cool.haxx.se
[mailto:curl-library-bounces_at_cool.haxx.se] On Behalf Of Daniel Stenberg
Sent: Monday, March 27, 2006 1:07 PM
To: libcurl development
Subject: Re: curl seg fault

On Mon, 27 Mar 2006, David Byron wrote:

> ./configure --disable-shared --enable-debug --enable-maintainer-mode
>
> This seems like the kind of thing that would have bitten people long
ago.
> Anyone see a build problem?

The problem seems to be that the curl app is mixing memory allocations
done by
libcurl or by itself and it calls free() on both types of alloc, while
it
*MUST* use curl_free() to free libcurl-allocated memory.

On unix-like systems this problem only occurs for debug-enabled builds
as they
enabled libcurls memory-debug-system that wrap the allocations with
debug
functionality.

Can you please check if this patch cures the problem for you:

--- src/main.c 20 Mar 2006 13:14:01 -0000 1.353
+++ src/main.c 27 Mar 2006 21:05:34 -0000
@@ -1892,7 +1892,9 @@
            /* we already have a string, we append this one
               with a separating &-letter */
            char *oldpost=config->postfields;
- config->postfields=aprintf("%s&%s", oldpost, postdata);
+ size_t newlen = strlen(oldpost) + strlen(postdata) + 2;
+ config->postfields=malloc(newlen);
+ snprintf(config->postfields, newlen, "%s&%s", oldpost,
postdata);
            free(oldpost);
            free(postdata);
          }

-- 
  Commercial curl and libcurl Technical Support:
http://haxx.se/curl.html