The plot thickens....

By placing "fprintf ( stderr,...)" calls at strategic points within libcurl
during 'FTP Get' process, I have some interesting data.

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 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.

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

Regards,
Dave

> -----Original Message-----
> From: Daniel Stenberg [SMTP:daniel_at_haxx.se]
> Sent: Thursday 20 December 2001 02:47 PM
> To: Bentham, David (Poole)
> Cc: libcurl Mailing list
> Subject: RE: libcurl on QNX 6
>
> On Thu, 20 Dec 2001 David.Bentham_at_poole.siemens.co.uk wrote:
>
> [sourceforge.net has completely disabled the ability to set the Reply-To:
> field in the outgoing mails. This forces everyone to use their
> reply-to-all
> button when replying to mails posted on lists hosted by sourceforge. No, I
> do
> not think this is good.]
>
> > > Sounds like a good idea. We need to narrow down where the bug occurs.
> A
> > > few simple log traces will rather quickly give results.
>
> > I'm progressing with this - and so far narrowed it down to
> > curl_ftp_connect(), and still going...
>
> Add a log in the Curl_ftpsendf() call, it sends a single FTP command...
>
> --
> Daniel Stenberg -- curl groks URLs -- http://curl.haxx.se/
>
>
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 2001-12-21