Processed: HDF 4.3.1 uploaded to unstable

[Antonio Valentino]

Dear Bas,

Il 16/08/25 12:49, Sebastiaan Couwenberg ha scritto:
> On 8/16/25 12:23 PM, Antonio Valentino wrote:
>> I was just wondering how to proceed in this case.
>> Do you have the chance to confirm my findings?
> 
> Yes, the same failures happen in my local build.
> 
>> Should I file an bug report against python-hdf4 (or maybe satpy)?
> 
> I'd start at the top of chain, get satpy upstream involved, it may be 
> their interaction with pyhdf that's the problem.
> 
> If you're able to reproduce the segfault in pyhdf, you can raise this 
> with its upstream.
> 
> Kind Regards,
> 
> Bas
> 

Finally I manage to spare some time to investigate the issue and I 
realized that there is a very similar problem on rioxarray.
For rioxarray I was able to identify a minimum set of tests (two) that, 
if run together, can trigger the issue. I reported it in [1].

The problem, both for satpy and rioxarray, seems to happen during the 
garbage collection of objects representing an HDF4 file.
In satpy it libhdf4 is used through pyhfd, while in rioxarray through 
rasterio and gdal.

Are you aware of any change in the libhdf4 API of v4.3.x that could lead 
to this kind of issues?

The satpy error apparently happens in a portion of the code that 
exploits treading.
Apart for making the debugging harder, I'm not sure this detail is 
relevant for the specific problem.

If my understanding is correct, the relevant portion of the satpy 
implementation is being rewritten in the upstream main branch for 
unrelated reasons. I will give it a try ASAP to understand if the new 
implementation has the same issues on debian.

Unfortunately, I have very few time to dedicate to it in this period.
satpy has been removed form testing and rioxarray will be removed very 
soon.
I'm sorry for that and I really hope that it does not creates too many 
issues.


[1] https://github.com/corteva/rioxarray/issues/869


kind regards
-- 
Antonio Valentino