Firstly, happy new year.

Secondly, some progress on this QNX6-libcurl fault.

After some mucking about with core dumps & gdb, it was found to be the
select(..) call in the function waitconnect(sockfd,timeout_msec) (in
connect.c) what was crashing.

It turns out that QNX sets FD_SETSIZE to only 32 in its <sys/select.h>
header, and as sockfd is passed in with a value of 40+, and as the
documentation states, socket descriptors > FD_SETSIZE screw up the
FD_ZERO/FD_SET macros, which I'm sure in turn will shaft select(..).

By setting FD_SETSIZE early in connect.c to override the QNX value
alleviates the crash.

Regards
Dave.

> -----Original Message-----
> From: Bjorn Reese [SMTP:breese_at_mail1.stofanet.dk]
> Sent: Friday 21 December 2001 04:31 PM
> To: curl-library_at_lists.sourceforge.net
> Subject: Re: libcurl on QNX 6
>
> Daniel Stenberg wrote:
> >
> > On Fri, 21 Dec 2001 David.Bentham_at_poole.siemens.co.uk wrote:
>
> > > 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)?
>
> There is a very high probability that this is a stack problem. I had a
> similar problem with trio on QNX, where one array on the stack used some
> 100 Kb. The problem was fixed by making the array smaller.
>
> I don't know what the default stack size on QNX is though.
>
>
This communication contains information which is confidential, and is for
the exclusive use of the addressee(s). If you are not a named addressee
please contact the sender immediately, and also delete the communication
from your system.

Any views or opinions presented are solely those of the author and do not
necessarily represent those of Siemens plc unless otherwise specifically
stated.
Received on 2002-01-02