Keyan

I fixed this bug here https://github.com/huumn/anno ... it required a modified bytes.Fields to keep track of indices ... I couldn't think of a better way to fix the issue given...

Thanks. Yes it does. No buffer reuse is occurring so I don't see the opportunity for a race. I've even run the code with -race and nothing is detected.

It uses the file load shown here, so I don't think a race is what's going on here. This is a copy and paste directly from the code -- heavily...

This is the guts of one goroutine, i.e. nothing declared within the scope of this function is shared with other goroutines, but multiple goroutines could execute this code each with...

Will do. I agree absolutely ruling that out is a good idea. I'm also thinking of recompiling the CGo stuff using https://github.com/google/sanitizers/wiki/MemorySanitizer to see if anything weird crops up. I'll...

Confirmed. With the same input buffer SHA256 it occasionally fails while most the time it succeeds. ``` 2018/04/25 13:38:02 sha256 of input file 7332fa39273bb3e2e6d91088b06f322989ce736fa03068422220db66bba27b54 libpng error: IDAT: unknown compression method...

Yep, happens with only a single goroutine resizing the images.

This is what I'm getting with -msan (compiling with clang): ``` (lldb) target create "./examples" Current executable set to './examples' (x86_64). (lldb) process launch -- -height 183 -width 408 -stretch...

Looks like the API has significantly changed -- the constructor that calls the offending function no longer exists in the project.

I see, thanks. I'll probably be messing around with the next few days to see if I can get all the uninitialized memory errors fixed at least. Hopefully there aren't...