On Mon, 27 Oct 2014 16:06:50 -0400
Dwayne MacKinnon <d...@ncf.ca> wrote:

> Update:
> 
> I've been able to fix the sftp problem. I tracked it down to kio_sftp.cpp, in 
> the sftpProtocol::sftpOpenConnection method.
> 
> From the error message, the problem was from this section of code (I wasn't 
> able to figure out which one. Probably the first one.)
> 
>  int timeout_sec = 30, timeout_usec = 0;
>  
>   kDebug(KIO_SFTP_DB) << "Creating the SSH session and setting options";
>   
>   // Set timeout
>   int rc = ssh_options_set(mSession, SSH_OPTIONS_TIMEOUT, &timeout_sec);
>   if (rc < 0) {
>     error(KIO::ERR_INTERNAL, i18n("Could not set a timeout."));
>     return false;
>   }
>   rc = ssh_options_set(mSession, SSH_OPTIONS_TIMEOUT_USEC, &timeout_usec);
>   if (rc < 0) {
>     error(KIO::ERR_INTERNAL, i18n("Could not set a timeout."));
>     return false;
>   }
> 
> 
> So, apparently the problem was in the ssh_options_set call to libssh.so . I 
> went looking at the libssh API docs. 
> 
> According to the libssh docs, the timeout values are supposed to be of type 
> long. As you can see above, the values are type int. 
> 
> I looked at the history of the kio_sftp.cpp file on KDE's git repository. The 
> code has always been of type int. On top of that, the author of the code is 
> one of the creators of libssh.
> 

In src/options.c of security/libssh, line 587 however it is clearly
hard-casted to a long integer.

Very nice spot though.

> So what I'm wondering is this: is there something about how we're compiling 
> the code now that is causing this problem? Could this be a clang vs gcc thing?
> 
> Cheers,
> DMK
> 

It's clearly relying on platform and compiler- (and compiler-option-)
specific behaviour. Some lines below the poor reading access that
happens to read buffer space or a prefix of the register it is not
supposed to read (depending on calling conventions in use) the code
binary ANDs away the poor prefix, however the constant is of type
signed int which AFAIK should be value-correctly promoted to it's long
counterpart, which means all bits of a long type on all supported
architectures, so there's some space for compiler specific behaviour

Anyway, this inconsistency is a bug and should be reported.

Alonso

Attachment: pgpLgV3mWTsYv.pgp
Description: PGP signature

_______________________________________________
kde-freebsd mailing list
kde-freebsd@kde.org
https://mail.kde.org/mailman/listinfo/kde-freebsd
See also http://freebsd.kde.org/ for latest information

Reply via email to