Changing MAX_PARAMETERS did not help nor did applying Gary's patch. I
have managed to trace the problem down but I have no idea why this is
happening.

The actual stack smashing was happening before my main code ever got
executed. Doing an strace I could see that the segfault happened right
after the last shared library was opened that curl required. I
recompiled curl and left out zlib, ssl, crypto, and sspi. After doing
that, my app runs fine.

What I don't understand is how opening libraries could cause the stack
to be smashed unless it was just too many for the stack size. I assume
that's what's happening since I don't see this when compiling without
lib pthread. I also discovered that my gcc is compiled with
--disable-thread and not --enable-thread=posix. I don't know if that
would have any affect but I can run pthreaded apps without that option.

Thanks for all the help.
Marshall

Marshall Crocker wrote:
> I changed the MAX_PARAMETERS value to 16 and will be testing the
> results shortly. If this doesn't work I'll try Gary's patch and test
> again. I'll go to valgrind if I still have a problem after that.
>
> I wasn't able to figure out where the application stack size is set.
> I don't know if this is controlled in the uClibc configuration or if
> it's a static value somewhere else.
> Marshall
>
> Daniel Stenberg wrote:
>> On Fri, 28 Jul 2006, Gary Maxwell wrote:
>>
>>> Well, going back and looking at the change, the hack wasn't as
>>> extensive as I remembered. This patch is generated off the current
>>> CVS tree:
>>
>> Thanks for posting this, I can't see anything wrong with this patch,
>> but the need for it made me think:
>>
>> 1 - its a pity having to do two malloc()s in such a lowlevel function
>> as they
>> are bound to make this function MUCH slower and thus slow down
>> lots of
>> operations that use *printf() functions.
>>
>> 2 - MAX_PARAMETERS is currently set to 128 which is insanely much and
>> nothing
>> in curl or libcurl is anywhere near this limit. The *printf()
>> functions
>> are already marked for getting removed from the public API in a
>> future
>> version so I think getting this limit more adjusted to libcurl
>> usage makes
>> lots of sense... I can't see any reason why we should support
>> more than 16
>> parameters.
>>
>> If we'd lower the limit to 16, would the patch really still be need
>> or wanted?
>>
>
Received on 2006-07-31