Magick Wand ReadImageFile() return error "The storage control block address is invalid."

[hailiangchen]

The error message returned is "The storage control block address is invalid."

Here is my code

`package main
import (
"fmt"
"os"

"gopkg.in/gographics/imagick.v3/imagick"

)
func main() {
imagick.Initialize()
defer imagick.Terminate()

mw := imagick.NewMagickWand()

file, err := os.Open("4.jpg")
if err != nil {
	fmt.Println(err)
}

err = mw.ReadImageFile(file)
if err != nil {
	fmt.Println(err)
}

}
`
Did I make a mistake

[justinfx]

That looks like a Windows specific error, with which I am not familiar. Does it only happen with the ReadImageFile method? Does it happen if you pass the file path directly to ReadImage?
A quick Google search implies that it might be related to Windows file system permissions during the read.

[hailiangchen]

There are no errors in either ReadImage or ReadImageBlob. Only the ReadImageFile has errors.
I also suspect Windows, but haven't tested it on Linux.
I did not search Google for this error.

That looks like a Windows specific error, with which I am not familiar. Does it only happen with the ReadImageFile method? Does it happen if you pass the file path directly to ReadImage?
A quick Google search implies that it might be related to Windows file system permissions during the read.

[justinfx]

Well yes, search results show it is windows specific. It would have something to do with the fdopen from C, used to open the file descriptor coming from the Go File

https://github.com/gographics/imagick/blob/v3.3.0/imagick/magick_wand_image.go#L2822

So something about that needs to be updated. A non windows user would need to push up a development branch to trigger appveyor CI to run a test that exercises this bug. Or a windows user could fix it and submit a patch.

For now you could work around it by calling the ReadImage api with the file path and let ImageMagick do all of the opening.

[justinfx]

I've started a branch with a test that passes in Linux, but would potentially fail with this error in windows (#231). I don't have windows available to confirm this so someone needs to test this and fix it, or I need to setup appveyor so I can try and iterate on the fix with CI

[justinfx]

@hailiangchen have you had a chance to test this on windows? I suppose I could try and set up windows CI soon.

[hailiangchen]

@hailiangchen have you had a chance to test this on windows? I suppose I could try and set up windows CI soon.
I pulled the branches im-7 and 229_win_fdopen and tested them separately on Windows.
Use ReadImageFile API, The error still occurs.
"The storage control block address is invalid."

[justinfx]

I've been trying to get a windows CI test running, but its proving very difficult to configure a windows build that uses cgo and linked dependencies. Iterating on this temp branch trying to get the test to pass: https://github.com/gographics/imagick/tree/ci_windows_test
I've gotten closer, but its still seemingly missing ImageMagick delegates and other strange quirks that cause a lot of tests to fail.

[justinfx]

I've now got a test branch working on github action CI and reproducing the error:
https://github.com/gographics/imagick/actions/runs/5565335024/jobs/10165610381#step:6:38

Will work to try and fix the issue and merge the windows CI support afterwards

[justinfx]

I've fixed this bug by switching from using C.fdopen(C.dup(f.Fd())) to passing the name of the file to C.fopen.

Released v3.4.3 (im7) and v2.6.3 (im6)