Skip to content
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

malloc(): corrupted top size after allocating array of polymorphic data type elements #1437

Open
pawosm-arm opened this issue Jan 15, 2024 · 0 comments

Comments

@pawosm-arm
Copy link
Collaborator

pawosm-arm commented Jan 15, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant