hyper: uninitialized memory being printed after end of HTTP response

I’m using curl commit 52fab72 compiled with Hyper 0.14.6 and the latest crustls commit. On Mac you can compile curl with the Hyper backend by using the following Homebrew formula:

brew install meterup/safe/curl

You can inspect the formula for yourself here: https://github.com/meterup/homebrew-safe.

Maybe 1 in every 20 HTTP requests I make, curl prints what appears to be uninitialized memory after the end of the HTTP response. It looks like this:

/usr/local/opt/curl/bin/curl \
    --silent \
    --show-error \
    --max-time "180" \
    --include \
    --request "GET" \
    --header "User-Agent: mcurl/1.176" \
    --header "Date: Thu, 22 Apr 2021 20:20:22 GMT" \
    --header "Keyname: api" \
    --header "Authorization:Meter secret" \
    https://meterapi.dev/v1/controllers/2011ba0629
HTTP/2 200 OK
date: Thu, 22 Apr 2021 20:20:46 GMT
content-type: application/json; charset=utf-8
content-length: 164
host-sid: 4a7cfb60-d6cd-4ecd-ba8f-9005b7d870f9
server: meter-api/1.178
strict-transport-security: max-age=31536000; preload
x-request-duration: 3.2ms

{
 "sid": "a1020efc-a6cc-4e3c-a5ea-36bd515a1d69",
 "created_at": "2020-11-24T20:55:56.792358Z",
 "updated_at": "2021-02-11T18:06:32.045429Z",
 "status": "online"
}
C61-4094-5BE81E368179.icc�1236_DeviceDescriptions_FactoryProfiles�45Uen_US_v15: if lost call 9252717005�7897Y555810816_DeviceDefaultProfileID�:;<>_DeviceModeDescriptions_DeviceProfileURL�4=WDefault_[/System/Library/Frameworks/ICADevices.framework/Versions/A/Resources/Camera RGB Profile.icc�@A^CustomProfiles�.B_F/Users/kevin/Library/ColorSync/Profiles/f.lux/fluxprofile-2531a33c.icc�DE^CustomProfiles�.F_F/Users/kevin/Library/ColorSync/Profiles/f.lux/fluxprofile-d43b9ac5.icc�HI^CustomProfiles�.J_S/Library/ColorSync/Profiles/Displays/LG TV-86777883-A061-5674-DC7D-9B1D37C869AB.icc�12LN�4M_CanoScan LiDE 220�OP8QUPY286326784Y287375360�:;RT�4S_Reflective Gray_E/System/Library/ColorSync/Profiles/Generic Gray Gamma 2.2 Profile.icc�:;VX�4W^Re

I have omitted some fields from the HTTP response since they contain private information and updated the Content-Length to match the new length of the HTTP response - 164 characters gets you to the } closing the JSON response. The original HTTP response contained extra JSON fields and was 528 characters, so the original Content-Length header read 528, if that matters. The server is written in Go and deployed to a Linux host; the extra memory bits reference stuff on my Mac so the extra memory is not being streamed from the server somehow.

I am not sure whether the issue exists in curl or in Hyper, but Jacob Hoffman-Andrews suggested it would be good to start here. I cannot reproduce this issue using other Curl TLS backends, for example openssl.