CPLDestroyMutex: Error = 16 (Device or resource busy)

[evetion]

This is something that happens on the exit of many tests over at GeoArrays, but I see the same here in the tests:
https://github.com/yeesian/ArchGDAL.jl/runs/3502488899?check_suite_focus=true#step:6:67

I'd say this is something that shouldn't happen, but I'm not sure. @visr any thoughts?

[visr]

Not directly. Something is perhaps not closed in the right order or something like that. Do you have a small example that we can start testing this out?

[mathieu17g]

The error message appears with Pkg.test("ArchGDAL") but not with include("runtests.jl") from the test directory

@visr have you already look into the possibility to make for Julia something equivalent of Python's <module>.UseExceptions() ?
This in order to identify better where the error message from come from.

[visr]

I think we have that, and it's enabled by default. Evey time you get a GDALError it is a Julia Exception thrown by an error in GDAL, see https://github.com/JuliaGeo/GDAL.jl/blob/master/src/error.jl.

If you can reliably trigger the issue, perhaps the quickest way to locate it is with some print statements in between the tests. Not sure why there is a difference between how you run the tests, unless the session and hence the handles are kept alive in one case but not the other.

[mathieu17g]

I have browsed the code of GDAL.jl/src/error.jl and GDAL.jl/gen/epilogue.jl, it is a really nice work you did there.

By commenting all includes and uncommenting then one by one in ArchGDAL/test/runtests.jl and running Pkg.test("ArchGDAL"), here are my findings:

• include("test_gdalutilities.jl"): that's where the GDAL error is written to stderr "CPLDestroyMutex: Error = 16 (Resource busy)" -> I will look after it
• include("test_rasterattrtable.jl"): produces a warning "There is no linear binning information." -> maybe it should be handled
• include("test_ospy_examples.jl"): produces a timing output. Is it necessary to keep the @time that must linger within ?
• include("test_images.jl"): Maybe add GDAL import at the beginning instead of relying on other test files

[visr]

Thanks!

Ok so probably the issue is in test_gdalutilities.jl. The @time can probably be removed, and indeed good to add a GDAL import to test_images.jl. For the warning, perhaps you can test/remove it by testing with https://docs.julialang.org/en/v1/stdlib/Test/#Test.@test_warn? Would be nice to not see it.

[mathieu17g]

Ok so probably the issue is in test_gdalutilities.jl

Narrowing a bit more, it happens in tests @test_throws GDAL.GDALError .... Something seems to need a release

[visr]

Looks like this is not in a do-block that automatically closes it, nor is it manually closed:

ArchGDAL.jl/test/test_gdalutilities.jl

Line 186 in 8f820c7

ds_small = AG.read("data/utmsmall.tif")

[mathieu17g]

Well it also happens here with a dataset closed with a do block :

ArchGDAL.jl/test/test_gdalutilities.jl

Lines 5 to 33 in 8f820c7

	@testset "test_gdalutilities.jl" begin
	AG.read("data/utmsmall.tif") do ds_small
	@testset "GDAL Error" begin
	@test_throws GDAL.GDALError AG.gdalinfo(
	ds_small,
	["-novalidoption"],
	)
	@test_throws GDAL.GDALError AG.unsafe_gdaltranslate(
	ds_small,
	["-novalidoption"],
	)
	@test_throws GDAL.GDALError AG.unsafe_gdalbuildvrt(
	[ds_small],
	["-novalidoption"],
	)
	@test_throws GDAL.GDALError AG.unsafe_gdaldem(
	ds_small,
	"hillshade",
	["-novalidoption"],
	)
	@test_throws GDAL.GDALError AG.unsafe_gdalnearblack(
	ds_small,
	["-novalidoption"],
	)
	@test_throws GDAL.GDALError AG.unsafe_gdalwarp(
	[ds_small],
	["-novalidoption"],
	)
	end

[visr]

This is the same file that is opened several times. Could it be that the handle is left open at line 186 causes issues at line 6 in a subsequent run?

[mathieu17g]

Ok I will move everything I can to a do block form, to see what happens.

[mathieu17g]

@visr I will make a PR to share code, because the issue seems to be trickier than expected.