You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When the compiler's frontend is generating a piece of IR for alloc04 call to the Fortran runtime library, for the polymorphic data type the len parameter is always 0 (namely, internal constant i64 0). The alloc04 function in flang runtime, when it detects that there is a zero-sized memory requirement, replaces it with 16-byte requirement, so there is always valid pointer to allocated memory returned. In the following example, slightly more than 16-bytes is allocated, and since it uses the Source parameter for the Allocate instruction which causes the allocated memory is immediately filled with n's, it is clearly going beyond the allocated memory:
program minalloc
Integer, parameter :: n = 7
Class(*),Pointer :: f1(:, :)
Allocate(f1(n, n), Source = n)
Print *, Size(f1, 1)
end
Note that it is sufficient to get rid of Source = n, and the problem goes unnoticed. But it is still there.
In case of latest glibc versions, this always causes malloc(): corrupted top size on a subsequent malloc (in the example above, it will happen in the Print instruction). In case of the old glibc, it is enough to increase the n parameter significantly (e.g. to 4096) and it will also start failing.
The text was updated successfully, but these errors were encountered:
When the compiler's frontend is generating a piece of IR for
alloc04
call to the Fortran runtime library, for the polymorphic data type thelen
parameter is always 0 (namely,internal constant i64 0
). The alloc04 function in flang runtime, when it detects that there is a zero-sized memory requirement, replaces it with 16-byte requirement, so there is always valid pointer to allocated memory returned. In the following example, slightly more than 16-bytes is allocated, and since it uses theSource
parameter for theAllocate
instruction which causes the allocated memory is immediately filled withn
's, it is clearly going beyond the allocated memory:Note that it is sufficient to get rid of
Source = n
, and the problem goes unnoticed. But it is still there.In case of latest glibc versions, this always causes
malloc(): corrupted top size
on a subsequent malloc (in the example above, it will happen in thePrint
instruction). In case of the old glibc, it is enough to increase then
parameter significantly (e.g. to 4096) and it will also start failing.The text was updated successfully, but these errors were encountered: