On Fri, 21 Dec 2001 David.Bentham_at_poole.siemens.co.uk wrote:

> The first problem is highlighted in Curl_connecthost() (connect.c). Just
> prior to the rc = connect(...) call, I printed out the connection
> parameters. Most were correct except for serv_addr.sin_port = 5376. This I
> assume is setup after it is determined that data->set.use_port = 5376
> earlier. This parameter is never set to anything by my application and the
> default 21 is expected.

The field 'serv_addr.sin_port' should be in network byte order (
serv_addr.sin_port = htons(port)). On many platforms, that'll make 21 turn up
like 5376 (21<<8) if the native byte order is byte-swapped compared with the
network order.

So, assuming that your native byte order is byte-swapped compared with the
network order, 5376 is correct.

> The second error occurred when calling socketerror() from within
> Curl_connecthost(). A debug print to stderr just prior to the call is
> reported, but the SIGSEGV occurred before the first debug print within
> socketerror() itself (placed before anything else in that function). By
> commenting all (except the debug print) within socketerror() (including the
> variable declarations), allowed a few more executions before the SIGSEGV.
>
> I hope this makes sense...
>
> To me this all seems to point to a stack problem. The fact the fault moves
> by removing a few valid executions from the execution path implies there is
> nothing particularly nasty within socketerror() but delays the point at
> which the stack craps out. I have also sort of assumed that the dodgy value
> in the port number is due to stack corruption too.

This does indeed sounds like some kind of stack problem. Have you measured
how much stack it uses and much stack you have (left)?

> Apparently we may be able to run under gdb, so thats the next task. Unless
> anyone out there knows a magical fix...?

Using gdb would be very good...

-- 
    Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/