From: Ricardo Wurmus <rekado@elephly.net>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix Devel <guix-devel@gnu.org>, guix-sysadmin@gnu.org
Subject: Re: Mumi service
Date: Wed, 22 Jan 2020 12:47:19 +0100 [thread overview]
Message-ID: <87a76fww54.fsf@elephly.net> (raw)
In-Reply-To: <877e2hcn77.fsf@gnu.org>
Ludovic Courtès <ludo@gnu.org> writes:
> Hi!
>
> Ricardo Wurmus <rekado@elephly.net> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> 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 #<bug 22883 7f9b77516ee0>)
>>> In mumi/messages.scm:
>>> 185:16 19 (patch-messages 22883)
>>> In debbugs/soap.scm:
>>> 163:19 18 (soap-invoke* #<procedure %gnu args> #<procedure get-bug-message-numbe…> …)
>>> 157:7 17 (soap-invoke _ _ . _)
>>> In sxml/simple.scm:
>>> 143:4 16 (xml->sxml _ #:namespaces _ #:declare-namespaces? _ #:trim-whitespace? _ …)
>>> 143:4 15 (loop #<input: string 7f9b77346d20> () #f _)
>>> 143:4 14 (loop #<input: string 7f9b77346d20> () #f _)
>>> 143:4 13 (loop #<input: string 7f9b77346d20> () #f _)
>>> 143:4 12 (loop #<input: string 7f9b77346d20> () #f _)
>>> 143:4 11 (loop #<input: string 7f9b77346d20> () #f _)
>>> 143:4 10 (loop #<input: string 7f9b77346d20> () #f _)
>>> In sxml/upstream/SSAX.scm:
>>> 1896:21 9 (_ #<input: string 7f9b77346d20> #f #<procedure 7f9b76d3a4d8 at sxml/s…> …)
>>> 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 #<input: string 7f9b77346d20> _ _)
>>> 72:4 5 (read-bytes #<input: string 7f9b77346d20> #vu8(10 32 98 121 32 109 97 …) …)
>>> In unknown file:
>>> 4 (port-read #<input: string 7f9b77346d20> #vu8(10 32 98 121 32 109 97 …) …)
>>> 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 …) …)
>>> In ice-9/suspendable-ports.scm:
>>> 284:18 2 (get-bytevector-n! #<input-output: string 7f9b77346d90> #vu8(10 32 98 …) …)
>>> 72:4 1 (read-bytes #<input-output: string 7f9b77346d90> #vu8(10 32 98 121 32 …) …)
>>> In unknown file:
>>> 0 (port-read #<input-output: string 7f9b77346d90> #vu8(10 32 98 121 32 …) …)
>>> 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’t understand this.
>
> Could it be that the ‘read!’ procedure of the custom binary input port
> (CBIP) returned by ‘make-delimited-input-port’ in (web response) returns
> 1024 when ‘count’ is in fact lower than 1024, or something along these
> lines? I would try adding ‘pk’ calls there to display ‘count’ and the
> return value.
>
> If that is true, then maybe the underlying issue is that
> ‘get-bytevector-n!’ in (ice-9 suspendable-ports) can return a value
> greater than ‘count’, presumably in the ‘fill-directly’ case.
>
> Hmmm!
FWIW, this problem also exists when using Guile 3.0.
I don’t know when it broke, but obviously there was a time (perhaps a
year ago) when it worked fine. Curious.
--
Ricardo
next prev parent reply other threads:[~2020-01-22 11:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-21 22:58 Mumi service Ludovic Courtès
2019-12-21 23:09 ` Ricardo Wurmus
2019-12-28 0:23 ` Ludovic Courtès
2020-01-22 11:47 ` Ricardo Wurmus [this message]
2020-02-12 8:54 ` Ricardo Wurmus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87a76fww54.fsf@elephly.net \
--to=rekado@elephly.net \
--cc=guix-devel@gnu.org \
--cc=guix-sysadmin@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.