-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
panics and/or EOF errors during GetPrinters request #30
Comments
Hi @kruftik, thank you for the good error description. i will have a look into it at the weekend |
@phin1x there was an occasion to look into ? |
@kruftik Can you explain in details the work around that you mentioned? |
@phin1x Did you get a chance to check out this issue? |
actually, I didn't dive into deep details. I have noticed that the response buffering before parsing prevents strange panics and that's it :-) my suppose there is some kind of "batching" during response writing from CUPS side and/or reading inside the stdlib and such a batching causes slice out-of-bounds panics since the library expects contant offsets / sizes etc. |
i have updated the http adatper to preload the ipp response into a buffer (the socket adapter already does this). i initially tried to avoid loading the entire ipp response into memory, as ipp responses can contain additional data (e.g. spool files or configs) which can be several gigabytes in size. please try the master branch and let me know if the problem is fixed. some notes on strings in the ipp protocol. strings are encoded by first specifying the length with an int16 and then the actual string content. we decode this by reading the size, creating a fixed byte-slice with the size read, and reading from the reader with the byte slice. this way the reader is always forwarded by the correct amount. potential padding is discarded by converting from a byte-slice to a string. |
I had a similar issue when getting printer attributes ( @phin1x your latest changes fixed the problem for me 👍🏻 thanks |
fixed in 1.6.1 |
(possibly connected with #29)
Present implementation of the http-based adapter has a strange behaviour with a partial or erroneous get printer list response. The
GetPrinters
request return only a part of the entire printers list or panics with "makeslice: len out of range" / completes with an EOF error. The source of the issue seems to be atAttributeDecoder#decodeString
method where the number of read bytes is ignored but sometimes the actual number of read bytes is less than the provided slice length.There is a possible work-around - read entire CUPS response into a
[]byte
slice and toResponseDecoder.Decode()
not the originalhttp.Response.Body
but thebytes.NewReader
of the slice.The behaviour can be reproduced with: https://github.com/kruftik/go-ipp-panics-repro
The text was updated successfully, but these errors were encountered: