In this case, the project was using Go's standard image library to operate on gifs, which itself uses Go's standard compression library to perform the compression. So the stack trace on error looked like: > error
> go's standard compression lib
> go's standard gif lib
> the project tries to write a gif to disk
It was very easy to grep the stdlib for the error message, which turned out to be in Go's compression lib. Great! I opened it up and started reading through it.Somehow, the compression lib was receiving an invalid parameter. Therefore, either Go's standard gif library was responsible for the problem (extremely unlikely) or the project was generating some kind of "invalid" gif data, or some gif settings that Go's gif lib didn't handle correctly when writing to disk. Printline debugging is the fastest way to figure out this type of problem. Print out everything, every single parameter, all the way up the stack. Eventually you'll spot the logic that's failing to handle the data. Trouble was, I had no clue how to modify go's stdlib. Nothing I did seemed to have any effect whatsoever. It sounds like you're saying the solution is to copy the gif lib to my local gopath like foo/gif, rebuild it there, then modify the project to import from foo/gif instead of image/gif. Ok, cool. I'll try this, thanks! Since the gif lib imports the compression lib, it sounds like I'll have to copy both libs, then try to modify the gif lib to use the local copy of the compression lib. Ok, sure. At least now I have a way of making progress. The project ran on the author's machine without any problems, so I bet I'm using a different version of Go. If I could figure out which version they were using, I could just downgrade to that. Problem solved. Unfortunately, I don't think this information is present in the project's repository, which is just a single .go file. (I guess I could check when the most recent commit was, then figure out what version of Go was in use back then...) Anyway. Thanks for your help. |