[h2root] explore/circumvent if occassional memory corruption issue stems from substring replacement #18234
Conversation
Test Results 20 files 20 suites 3d 18h 32m 0s ⏱️ For more details on these failures, see this check. Results for commit e06b2ec. ♻️ This comment has been updated with latest results. |
|
@pcanal @hageboeck @couet @guitargeek |
We should open a issue to record those. |
What about the libgfortran dyld failure on mac? |
added to #14682 |
We indeed need to 'fix' that part before merging. |
I see this message on the CI build for instance on macphsft31. I checked on that one and gfortran seems properlly installed: I checked the other Macs : It is the same |
Could it be that this related to #19134 ? @guitargeek should I try to apply your #19135 here? |
|
I don't think adding something hardcoded to the RPATH is a good idea here, because on the users system the But let's see if that actually works 😆 |
ferdymercury
changed the title
[nfc] comment on how to enable warnings and sanitizer to debug some asan issues that are still present in h2root
…lacement by adding a space, we create an extra char that will be substituted by c, rather than appending to the string
| // "px" is a string being changed to "pxc" in the fortran side; since it's a temporary on C's side, | ||
| // we need a buffer of at least 3 chars on Cs side, too. Predefine it as a extra variable "px " since that way | ||
| // the space will be replaced by 'c' on the preallocated memory, instead of appending a new char (new memory) to "px". | ||
| auto opt = PASSCHAR("px "); | ||
| hropen(lun,PASSCHAR("example"),PASSCHAR(file_in),opt,record_size,ier,7,strlen(file_in),2); |
There was a problem hiding this comment.
This explanation does not make sense to me because, as far as I can see, the string passed into HROPEN is copied into a character array of length 8:
root/misc/minicern/src/hbook.f
Lines 250 to 251 in cc14662
Appending a space should not change things; if it does, it's either moving or hiding another problem...
There was a problem hiding this comment.
Yes, it's surprising that march_native no longer crashes with this fix.
I have no idea about Fortran, but, maybe the problem is that the assumed length of CHOPTT in Fortran is off by one, in the sense that it also counts the null-terminator as part of the length, so adding a space forces the copy to work correctly?
There was a problem hiding this comment.
It could also be some of these other issues:
#11657
#14682 (comment)
There was a problem hiding this comment.
@hahnjo it's confirmed. I added this debug line:
CHOPT=CHOPTT
print*, 'HROPEN0: "',CHOPT,'"',LEN(CHOPTT)
And I get:
On mac15 and mac-beta:
HROPEN0: "px " 2
On mac13 and mac14:
HROPEN0: "px exam" 2
which is the sum of "px" and "example" separate arguments in C.
The question now is if this is a gfortran-version-compiler-bug, or if it's an undefined behavior, so we need to fix it by hand.
If I add:
DO 11 I=LEN(CHOPTT)+1,8
CHOPT(I:I) = ' '
11 CONTINUE
Then it seems to work fine in mac13, but not on mac14. See https://github.com/root-project/root/actions/runs/15984458534/job/45085965269?pr=19191
Maybe related: https://www.tek-tips.com/threads/string-copy.1609892/post-6335242
This Pull request:
Changes or fixes:
By adding a space, we create an extra char that, on Fortran's side will be substituted by c, rather than appending to the (temporary passed as argument C-)string.
Related discussion: https://github.com/root-project/root/pull/15915/files
Fixes #14155