From nmav at gnutls.org Fri May 2 12:59:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Fri May 2 12:59:02 2003 Subject: [gnutls-dev] [Bugs] building 0.9.6 failed on Solaris 8 In-Reply-To: <3EAC9D1B.9000704@sun.com> References: <3EAC9D1B.9000704@sun.com> Message-ID: <20030501204525.GB975@gnutls.org> On Mon, Apr 28, 2003 at 11:16:43AM +0800, Sean Gao wrote: > Hi, there > Recently I have tried to build 0.9.6 on Solaris 8 for times but > unfortunately it is always failed. > I have tried with both Forte 6.0 update2 (cc5.3) and gcc 3.2, and after > correcting some syntax > checking issues, the building process always ends with errors when it > try to make gnutls-serv in > the src subdirectory. > I have attached the output of bothing building process with this > e-mail. I would be very > appreciated if you could provide me some help on this issue. This should be because the exported symbols are not correct in 0.8.6. Try to remove the -export-symbols parameter to libtool from the makefiles, or use the 0.9.x releases. In linux there was no problem because the exported symbols are ignored by the libtool (and thus by the linker). > Cheers > -Sean -- Nikos Mavroyanopoulos From sean.gao at sun.com Thu May 8 16:23:19 2003 From: sean.gao at sun.com (Sean Gao) Date: Thu May 8 16:23:19 2003 Subject: [gnutls-dev] Patch for 0.9.5 for building with Forte 6 update 2 on Solaris/Sparc Message-ID: <3EB73274.9000000@sun.com> Hi, there Just completing building 0.9.5 on Solaris with Forte 6 update 2, and I have done some modifications before success. Attached is a proposed patch, and here are some comments: 1. gnutls-0.9.5/includes/gnutls/openssl.h forte seems not accepting an empty struct without any member ... gnutls-0.9.5/lib/gnutls_cipher.c the const keyword makes forte failing gnutls-0.9.5/libextra/gnutls_srp.c the "return FUNCTION();" is not accept for a void return type function. 2. Even if I define __BUILTIN_VA_ARG_INCR or __sparc, it seems that the including header file /usr/include/alloca.h is not preprocessed as expected since it always says that alloca is an undefined symbol during linking process .... I have to do some changes, but my approach seems work-around only, hope you guys can help to correct me. Thanks, :-) 3. In the file gnutls-0.9.5.new/lib/x509/x509.c, if not giving tmp.data a value, it will cause core dump ... It should be a neglect forgetting to do so., Hope these could be some helpful and be taken into account Cheers, -Sean -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: apatch.txt URL: From nmav at gnutls.org Fri May 9 17:11:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Fri May 9 17:11:02 2003 Subject: [gnutls-dev] Patch for 0.9.5 for building with Forte 6 update 2 on Solaris/Sparc In-Reply-To: <3EB73274.9000000@sun.com> References: <3EB73274.9000000@sun.com> Message-ID: <20030508205048.GB5084@gnutls.org> On Tue, May 06, 2003 at 11:56:36AM +0800, Sean Gao wrote: > Hi, there > Just completing building 0.9.5 on Solaris with Forte 6 update 2, > and I have done some modifications > before success. Attached is a proposed patch, and here are some > comments: > 1. gnutls-0.9.5/includes/gnutls/openssl.h forte seems not > accepting an empty struct without any member ... > gnutls-0.9.5/lib/gnutls_cipher.c the const > keyword makes forte failing > gnutls-0.9.5/libextra/gnutls_srp.c the "return > FUNCTION();" is not accept for a void return type function. > 2. Even if I define __BUILTIN_VA_ARG_INCR or __sparc, it seems > that the including header file > /usr/include/alloca.h is not preprocessed as expected since it > always says that alloca is an undefined > symbol during linking process .... I have to do some changes, > but my approach seems work-around > only, hope you guys can help to correct me. Thanks, :-) > 3. In the file gnutls-0.9.5.new/lib/x509/x509.c, if not giving > tmp.data a value, it will cause core dump ... > It should be a neglect forgetting to do so., > Hope these could be some helpful and be taken into account Thank you. Most of them have been solved now in the cvs, and they will be included in the next 0.9.x release. > > Cheers, > -Sean -- Nikos Mavroyanopoulos From nmav at gnutls.org Sun May 11 23:37:03 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Sun May 11 23:37:03 2003 Subject: [gnutls-dev] gnutls 0.8.7 Message-ID: <20030511213942.GA9106@gnutls.org> Version 0.8.7 is out. The changes since 0.8.6 are: - Some corrections in the Makefiles, to prevent some build errors in solaris. - Corrections in the TLS layer openpgp certificate packet parser. -- Nikos Mavroyanopoulos From gray at Mirddin.farlep.net Tue May 27 20:20:02 2003 From: gray at Mirddin.farlep.net (Sergey Poznyakoff) Date: Tue May 27 20:20:02 2003 Subject: [gnutls-dev] [PATCH] bug in lib/gnutls_buffers.c Message-ID: <200305271819.h4RIJYI16118@Mirddin.farlep.net> Hello, The buffering mechanism in gnutls_buffers.c does not work when the user-defined pull function is used. Here's the short synopsis: The comment to _gnutls_io_clear_peeked_data() states that `this function is only used with berkeley style sockets.', however no provision is made to ensure this is so. This causes the function to be called even if the pull function is used. Now, what happens is that calling _gnutls_io_clear_peeked_data() after _gnutls_read(..., MSG_PEEK) blocks the program, since it actually attempts to read the same data twice. Attached is the patch that corrects the bug. Regards, Sergey -------------- next part -------------- Index: lib/gnutls_buffers.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/gnutls_buffers.c,v retrieving revision 2.104 diff -p -u -r2.104 gnutls_buffers.c --- lib/gnutls_buffers.c 24 Mar 2003 17:21:54 -0000 2.104 +++ lib/gnutls_buffers.c 27 May 2003 17:22:46 -0000 @@ -429,7 +429,8 @@ ssize_t _gnutls_io_read_buffered( gnutls if (ret2 > 0) { _gnutls_read_log("RB-PEEK: Read %d bytes in PEEK MODE.\n", ret2); _gnutls_read_log("RB-PEEK: Have %d bytes into buffer. Adding %d bytes.\nRB: Requested %d bytes\n", session->internals.record_recv_buffer.length, ret2, sizeOfPtr); - session->internals.have_peeked_data = 1; + if (!session->internals._gnutls_pull_func) + session->internals.have_peeked_data = 1; session->internals.record_recv_buffer.length += ret2; } From nmav at gnutls.org Tue May 27 23:36:01 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue May 27 23:36:01 2003 Subject: [gnutls-dev] [PATCH] bug in lib/gnutls_buffers.c In-Reply-To: <200305271819.h4RIJYI16118@Mirddin.farlep.net> References: <200305271819.h4RIJYI16118@Mirddin.farlep.net> Message-ID: <20030527213849.GA1737@gnutls.org> On Tue, May 27, 2003 at 09:19:33PM +0300, Sergey Poznyakoff wrote: > Hello, > The buffering mechanism in gnutls_buffers.c does not work when > the user-defined pull function is used. Here's the short > synopsis: > The comment to _gnutls_io_clear_peeked_data() states that `this > function is only used with berkeley style sockets.', however no > provision is made to ensure this is so. This causes the function > to be called even if the pull function is used. Now, what happens > is that calling _gnutls_io_clear_peeked_data() after > _gnutls_read(..., MSG_PEEK) blocks the program, since it actually > attempts to read the same data twice. > Attached is the patch that corrects the bug. Thank you for the report and the patch. Does the attached patch also solve the problem? > Regards, > Sergey -- Nikos Mavroyanopoulos -------------- next part -------------- Index: gnutls_buffers.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/gnutls_buffers.c,v retrieving revision 2.104 diff -u -u -r2.104 gnutls_buffers.c --- gnutls_buffers.c 24 Mar 2003 17:21:54 -0000 2.104 +++ gnutls_buffers.c 27 May 2003 21:33:30 -0000 @@ -331,7 +331,7 @@ size_t min; int buf_pos; char *buf; - int recvlowat = RCVLOWAT; + int recvlowat; int recvdata, alloc_size; *iptr = session->internals.record_recv_buffer.data; @@ -341,13 +341,22 @@ return GNUTLS_E_INVALID_REQUEST; } - /* leave peeked data to the kernel space only if application data - * is received and we don't have any peeked - * data in gnutls session. + /* If an external pull function is used, then do not leave + * any data into the kernel buffer. */ - if ( recv_type != GNUTLS_APPLICATION_DATA - && session->internals.have_peeked_data==0) + if (session->internals._gnutls_pull_func != NULL) { recvlowat = 0; + } else { + /* leave peeked data to the kernel space only if application data + * is received and we don't have any peeked + * data in gnutls session. + */ + if ( recv_type != GNUTLS_APPLICATION_DATA + && session->internals.have_peeked_data==0) + recvlowat = 0; + else recvlowat = RCVLOWAT; + } + /* calculate the actual size, ie. get the minimum of the From nmav at gnutls.org Tue May 27 23:39:02 2003 From: nmav at gnutls.org (Nikos Mavroyanopoulos) Date: Tue May 27 23:39:02 2003 Subject: [gnutls-dev] [PATCH] bug in lib/gnutls_buffers.c In-Reply-To: <200305271819.h4RIJYI16118@Mirddin.farlep.net> References: <200305271819.h4RIJYI16118@Mirddin.farlep.net> Message-ID: <20030527214213.GA2423@gnutls.org> On Tue, May 27, 2003 at 09:19:33PM +0300, Sergey Poznyakoff wrote: > Hello, > The buffering mechanism in gnutls_buffers.c does not work when > the user-defined pull function is used. Here's the short > synopsis: > The comment to _gnutls_io_clear_peeked_data() states that `this > function is only used with berkeley style sockets.', however no > provision is made to ensure this is so. This causes the function > to be called even if the pull function is used. Now, what happens > is that calling _gnutls_io_clear_peeked_data() after > _gnutls_read(..., MSG_PEEK) blocks the program, since it actually > attempts to read the same data twice. > Attached is the patch that corrects the bug. Thank you for the report and the patch. Does the attached patch also solve the problem? > Regards, > Sergey -- Nikos Mavroyanopoulos -------------- next part -------------- Index: gnutls_buffers.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/gnutls_buffers.c,v retrieving revision 2.104 diff -u -u -r2.104 gnutls_buffers.c --- gnutls_buffers.c 24 Mar 2003 17:21:54 -0000 2.104 +++ gnutls_buffers.c 27 May 2003 21:33:30 -0000 @@ -331,7 +331,7 @@ size_t min; int buf_pos; char *buf; - int recvlowat = RCVLOWAT; + int recvlowat; int recvdata, alloc_size; *iptr = session->internals.record_recv_buffer.data; @@ -341,13 +341,22 @@ return GNUTLS_E_INVALID_REQUEST; } - /* leave peeked data to the kernel space only if application data - * is received and we don't have any peeked - * data in gnutls session. + /* If an external pull function is used, then do not leave + * any data into the kernel buffer. */ - if ( recv_type != GNUTLS_APPLICATION_DATA - && session->internals.have_peeked_data==0) + if (session->internals._gnutls_pull_func != NULL) { recvlowat = 0; + } else { + /* leave peeked data to the kernel space only if application data + * is received and we don't have any peeked + * data in gnutls session. + */ + if ( recv_type != GNUTLS_APPLICATION_DATA + && session->internals.have_peeked_data==0) + recvlowat = 0; + else recvlowat = RCVLOWAT; + } + /* calculate the actual size, ie. get the minimum of the From gray at Mirddin.farlep.net Tue May 27 23:51:02 2003 From: gray at Mirddin.farlep.net (Sergey Poznyakoff) Date: Tue May 27 23:51:02 2003 Subject: [gnutls-dev] [PATCH] bug in lib/gnutls_buffers.c In-Reply-To: Your message of Wed, 28 May 2003 00:38:49 +0300 <20030527213849.GA1737@gnutls.org> References: <200305271819.h4RIJYI16118@Mirddin.farlep.net> <20030527213849.GA1737@gnutls.org> Message-ID: <200305272152.h4RLqMI26161@Mirddin.farlep.net> Hello Nikos, > Does the attached patch also solve the problem? Yes, it does. It keeps `have_peeked_data' member set to zero, which effectively disables the function _gnutls_io_clear_peeked_data(), and that solves the problem. Regards, Sergey From gray at Mirddin.farlep.net Wed May 28 11:50:02 2003 From: gray at Mirddin.farlep.net (Sergey Poznyakoff) Date: Wed May 28 11:50:02 2003 Subject: [gnutls-dev] [PATCH] bug in lib/gnutls_buffers.c Message-ID: <200305271742.h4RHgYI09300@Mirddin.farlep.net> Hello, The buffering mechanism in gnutls_buffers.c does not work when the user-defined pull function is used. Here's the short synopsis: The comment to _gnutls_io_clear_peeked_data() states that `this function is only used with berkeley style sockets.', however no provision is made to ensure this is so. This causes the function to be called even if the pull function is used. Now, what happens is that calling _gnutls_io_clear_peeked_data() after _gnutls_read(..., MSG_PEEK) blocks the program, since it actually attempts to read the same data twice. Attached is the patch that corrects the bug. Regards, Sergey -------------- next part -------------- Index: lib/gnutls_buffers.c =================================================================== RCS file: /cvs/gnutls/gnutls/lib/gnutls_buffers.c,v retrieving revision 2.104 diff -p -u -r2.104 gnutls_buffers.c --- lib/gnutls_buffers.c 24 Mar 2003 17:21:54 -0000 2.104 +++ lib/gnutls_buffers.c 27 May 2003 17:22:46 -0000 @@ -429,7 +429,8 @@ ssize_t _gnutls_io_read_buffered( gnutls if (ret2 > 0) { _gnutls_read_log("RB-PEEK: Read %d bytes in PEEK MODE.\n", ret2); _gnutls_read_log("RB-PEEK: Have %d bytes into buffer. Adding %d bytes.\nRB: Requested %d bytes\n", session->internals.record_recv_buffer.length, ret2, sizeOfPtr); - session->internals.have_peeked_data = 1; + if (!session->internals._gnutls_pull_func) + session->internals.have_peeked_data = 1; session->internals.record_recv_buffer.length += ret2; }