Skip to content
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

Closed
kruftik opened this issue Jan 16, 2023 · 8 comments
Closed

panics and/or EOF errors during GetPrinters request #30

kruftik opened this issue Jan 16, 2023 · 8 comments
Labels
good first issue Good for newcomers

Comments

@kruftik
Copy link

kruftik commented Jan 16, 2023

(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 at AttributeDecoder#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 to ResponseDecoder.Decode() not the original http.Response.Body but the bytes.NewReader of the slice.

The behaviour can be reproduced with: https://github.com/kruftik/go-ipp-panics-repro

@phin1x
Copy link
Owner

phin1x commented Jan 17, 2023

Hi @kruftik, thank you for the good error description. i will have a look into it at the weekend

@phin1x phin1x added the good first issue Good for newcomers label Jan 17, 2023
@kruftik
Copy link
Author

kruftik commented Feb 4, 2023

@phin1x there was an occasion to look into ?

@anirudhagarwal1
Copy link

@kruftik Can you explain in details the work around that you mentioned?

@anirudhagarwal1
Copy link

@phin1x Did you get a chance to check out this issue?

@kruftik
Copy link
Author

kruftik commented Mar 2, 2023

@kruftik Can you explain in details the work around that you mentioned?

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.

@phin1x
Copy link
Owner

phin1x commented Mar 25, 2023

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.

@jameshalsall
Copy link
Contributor

I had a similar issue when getting printer attributes (ipp.OperationGetPrinterAttributes) - I would see EOF errors intermittently

@phin1x your latest changes fixed the problem for me 👍🏻 thanks

@phin1x phin1x closed this as completed Jun 11, 2023
@phin1x
Copy link
Owner

phin1x commented Jun 11, 2023

fixed in 1.6.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants