Re: Mumi service

[Ricardo Wurmus]

Ricardo Wurmus <address@hidden> writes:

> Ludovic Courtès <address@hidden> writes:
>
>> Hi!
>>
>> Ricardo Wurmus <address@hidden> skribis:
>>
>>> Ludovic Courtès <address@hidden> 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.

Just FYI: I begin almost every day by logging in to ci.guix.gnu.org to
restart mumi as it has (is is about to) become unusable due to the leak.

It would be good if we could identify and solve the problem.  I suppose
as a first step we would need to monkey patch (web response) in Guile
Debbugs to introduce some instrumentation (i.e. inserting “pk” here and
there).

--
Ricardo