From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ricardo Wurmus Subject: Re: Mumi service Date: Wed, 22 Jan 2020 12:47:19 +0100 Message-ID: <87a76fww54.fsf@elephly.net> References: <878sn5mgk2.fsf@gnu.org> <87eewxp96q.fsf@elephly.net> <877e2hcn77.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:40302) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iuETx-0005vB-Qq for guix-devel@gnu.org; Wed, 22 Jan 2020 06:47:40 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iuETw-0006Ob-Ko for guix-devel@gnu.org; Wed, 22 Jan 2020 06:47:37 -0500 In-reply-to: <877e2hcn77.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: Ludovic =?utf-8?Q?Court=C3=A8s?= Cc: Guix Devel , guix-sysadmin@gnu.org Ludovic Court=C3=A8s writes: > Hi! > > Ricardo Wurmus skribis: > >> Ludovic Court=C3=A8s writes: > > [...] > >>> However, the currently packaged snapshot crashes when trying to retrieve >>> information about a bug: >>> >>> --8<---------------cut here---------------start------------->8--- >>> $ /gnu/store/qw2c84gnwk3sgivh2i8x98xx5gx73vxl-mumi-0.0.0-5.8a57c87/bin/= mumi >>> GET /issue/22883 >>> In mumi/web/server.scm: >>> 38:9 23 (handler _ _ _) >>> In mumi/web/controller.scm: >>> 38:21 22 (render-with-error-handling _ _) >>> 104:21 21 (_) >>> In mumi/web/view/html.scm: >>> 274:19 20 (issue-page #) >>> In mumi/messages.scm: >>> 185:16 19 (patch-messages 22883) >>> In debbugs/soap.scm: >>> 163:19 18 (soap-invoke* # # =E2=80=A6) >>> 157:7 17 (soap-invoke _ _ . _) >>> In sxml/simple.scm: >>> 143:4 16 (xml->sxml _ #:namespaces _ #:declare-namespaces? _ #:trim= -whitespace? _ =E2=80=A6) >>> 143:4 15 (loop # () #f _) >>> 143:4 14 (loop # () #f _) >>> 143:4 13 (loop # () #f _) >>> 143:4 12 (loop # () #f _) >>> 143:4 11 (loop # () #f _) >>> 143:4 10 (loop # () #f _) >>> In sxml/upstream/SSAX.scm: >>> 1896:21 9 (_ # #f # =E2=80=A6) >>> In sxml/ssax/input-parse.scm: >>> 103:21 8 (next-token _ (#\< #\& #\return) _ _) >>> In ice-9/suspendable-ports.scm: >>> 683:15 7 (read-delimited _ _ _) >>> 184:27 6 (fill-input # _ _) >>> 72:4 5 (read-bytes # #vu8(10 32 98 12= 1 32 109 97 =E2=80=A6) =E2=80=A6) >>> In unknown file: >>> 4 (port-read # #vu8(10 32 98 121= 32 109 97 =E2=80=A6) =E2=80=A6) >>> In web/response.scm: >>> 254:22 3 (read! #vu8(10 32 98 121 32 109 97 105 108 46 109 101 115 = 115 97 103 =E2=80=A6) =E2=80=A6) >>> In ice-9/suspendable-ports.scm: >>> 284:18 2 (get-bytevector-n! # #v= u8(10 32 98 =E2=80=A6) =E2=80=A6) >>> 72:4 1 (read-bytes # #vu8(10 3= 2 98 121 32 =E2=80=A6) =E2=80=A6) >>> In unknown file: >>> 0 (port-read # #vu8(10 32= 98 121 32 =E2=80=A6) =E2=80=A6) >>> In procedure custom_binary_input_port_read: Value out of range: 1024 >>> --8<---------------cut here---------------end--------------->8--- >>> >>> Does that ring a bell, Ricardo? Should we update to a newer snapshot? >> >> This is exactly the same bug I hit when using mumi with (fibers web >> server). With just the regular Guile (web server) it works fine but >> seemingly leaks file handles until it is restarted. >> >> I don=E2=80=99t understand this. > > Could it be that the =E2=80=98read!=E2=80=99 procedure of the custom bina= ry input port > (CBIP) returned by =E2=80=98make-delimited-input-port=E2=80=99 in (web re= sponse) returns > 1024 when =E2=80=98count=E2=80=99 is in fact lower than 1024, or somethin= g along these > lines? I would try adding =E2=80=98pk=E2=80=99 calls there to display = =E2=80=98count=E2=80=99 and the > return value. > > If that is true, then maybe the underlying issue is that > =E2=80=98get-bytevector-n!=E2=80=99 in (ice-9 suspendable-ports) can retu= rn a value > greater than =E2=80=98count=E2=80=99, presumably in the =E2=80=98fill-dir= ectly=E2=80=99 case. > > Hmmm! FWIW, this problem also exists when using Guile 3.0. I don=E2=80=99t know when it broke, but obviously there was a time (perhaps= a year ago) when it worked fine. Curious. -- Ricardo