When I start xchat it keeps saying this to stderr SSL_read/read: Resource temporarily unavailable. And the link to the server gets closed. In the channel tabs, xchat says: -- Disconnected (Illegal seek)
This is probably an openssl bug.
poll([{fd=3, events=POLLIN}, {fd=5, events=POLLIN}, {fd=24, events=POLLIN|POLLPR I}, {fd=20, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=9, event s=POLLIN|POLLPRI}, {fd=8, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI, revents=POLLIN}], 8, 145) = 1 read(11, "\27\3\0\0 ", 5) = 5 read(11, "\30\1\271\n\204\'.\227\372\226g\177\335\267\261\235\17"..., 32) = 32 read(11, "\27\3\0\0000", 5) = 5 read(11, "\304X\335C_\261\24\204b\304T\6\25\303\300\177D\346\232"..., 48) = 48 time(NULL) = 1160135921 stat64("/etc/localtime", {st_mode=S_IFREG|0644, st_size=1323, ...}) = 0 time(NULL) = 1160135921 read(11, 0x103a0a20, 5) = -1 EAGAIN (Resource temporarily unavai lable) dup(2) = 4 fcntl64(4, F_GETFL) = 0x2 (flags O_RDWR) fstat64(4, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x338 fd000 _llseek(4, 0, 0x7fadf808, SEEK_CUR) = -1 ESPIPE (Illegal seek) write(4, "SSL_read/read: Resource temporar"..., 48) = 48 close(4) = 0
I don't believe it much. I'd rather suppose that xchat doesn't call openssl correctly or something like that. Could you try to reproduce this problem with various openssl and xchat version combinations?
I'm rebuilding both with debug info now, and I'll work out precisely what's going on. It looks like we're hitting the SSL_ERROR_SYSCALL case here in xchat's common/ssl.c: int _SSL_recv (SSL * ssl, char *buf, int len) { int num; num = SSL_read (ssl, buf, len); switch (SSL_get_error (ssl, num)) { case SSL_ERROR_SSL: /* ??? */ __SSL_fill_err_buf ("SSL_read"); fprintf (stderr, "%s\n", err_buf); break; case SSL_ERROR_SYSCALL: /* ??? */ perror ("SSL_read/read"); break;
My theory (I didn't study the xchat code) is that it sets the SSL socket to nonblocking I/O and then it doesn't properly handle the situation where EAGAIN is returned -> should simply go back to poll() and wait for more data. But I might be wrong.
Joy. With my own builds of openssl and xchat it doesn't happen any more. Yet I definitely saw it with pristine rawhide on both i386 and PowerPC. Will revert to official packages and download the matching debuginfo.
Created attachment 137968 [details] Patch to do what Tomas said. Looks like Tomas was right, and this fixes it. Thanks.
This is still happening in FC6.
This exact patch has been applied upstream in 2.6.8, so the 2.8.4 builds in F7 updates and Rawhides already have the fix.