-
-
Notifications
You must be signed in to change notification settings - Fork 265
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fortranlib_test test aborts on Fedora Rawhide i686 #4926
Comments
Hi, I experience the very same failure on Debian unstable for architectures armel and armhf. This is a blocker for transitioning Debian to HDF5 1.14. @brtnfld any chance to have a patch soon? |
For what it's worth, I've run a git bisect on this issue between tags hdf5_1.14.4.3 and hdf5_1.14.5. And the first bad commit is a354576. |
Similar failure also on Alpine Linux Edge on all architectures: Describe the bug
Platform (please complete the following information)
|
I've run another git bisect on the develop branch between april 22nd and may 7th and found abf8b01 as the first bad commit:
@brtnfld I hope you can take over from here. Please let me know if you need more information. EDIT: Fixed the commit link which was wrong. Sorry about that. |
Full backtrace:
|
As I understand it the error This corruption occurs for 32bit architectures only and seems caused by this line in the test:
If I replace the empty string parameter with a 14 chars string then the whole test is successful. |
Correct, that is what I discovered for #5036. The only test that fails is with h5rget_obj_name_f with optional parameters and a blank string (or a smaller string) being passed in. But with the optional parameters, it does not use the string, so it really should not matter. It seg faults when returning from the Fortran call; the C call is successful. If I specify a specific string length to pass to the API, I can get it to pass, as you've seen. I think it is probably a compiler issue, but I've had not had the time to investigate it further. We are not typically testing with GCC 14.x. Is it possible to use an older version of the compiler to see if it is problem? We've not had this issue and we test with a wide variety of compilers. |
I've tested with GCC 13 and GCC 12. Same problem. EDIT: Actually it fails on Debian bookworm as well. EDIT2: I've tested on Debian 11 (bullseye) with GCC 9 and GCC 10. Same error. If this is a compiler issue it is very old then. |
Describe the bug
Platform (please complete the following information)
The text was updated successfully, but these errors were encountered: