Ludovic Courtès <[email protected]> writes:
> Hi! > > Ricardo Wurmus <[email protected]> skribis: > >> Ludovic Courtès <[email protected]> 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
