@urbanjost yeah, unfortunately I think the problem will be very very hard to find. Actually, changing that given dimension which I speak abount in the main question, the behaviour changes, either hanging at some allocate or deallocate statement.
@JohnCampbell as for your suggestion n. 1, it was already like that. However, it hangs also using STAT= inquiry variable… which I don’t know which could be the reason.
For suggestions n. 2 and 3, many thanks. However, never used function GlobalMemoryStatusEx(mdata). How could I integrate it in the code base? What is mdata(16)?
I’ll also try to remove /check:all, and see how it behaves.
It looks like you need to insert a DEALLOCATE() statement in your code to find where the problem first occurs. Most likely it will be after some external library call where you have mismatched arguments or incorrect argument values, but who knows? Start with locations that are close to the original ALLOCATE() (where it will be successful) and then do a binary search between there and the location where you know it fails. If you have a situation where the ALLOCATE/DEALLOCATE pair fail when right next to each other, then do the binary search with that pair of statements to find where the corruption first occurs.
Is it possible for you to post a zip of your code including the Microsoft Visual Studio (VS) solution and project files some place online just temporarily (Dropbox?) so interested readers can take a look and give you guidance? You can private-message (PM) the link if you seek some confidentiality with your code and effort. This is assuming you are not using GitHub and your code is intentionally not part of an open repository.
I suggest this because:
a) you’ve been at this for several days and facing more ICEs and stuff while this problem is still outstanding,
b) you appear to be using Windows OS and Intel Fortran compiler and its integration with Microsoft Visual Studio debugging IDE and with this combination, generally the problem source becomes evident soon enough.
At least ii is so in our experience which has been around several mid-size codebases i.e., a few dozen VS projects with about hundreds of source files covering around 200-600K lines of code in each project with a lot of C++ and C#/VB projects and a few dependent Fortran library projects (alas diminishing in number). Unless you’re dealing with large codes with extreme complexity, you can be confident with your IDE toolsets here to help you determine the root cause (s) of the memory issue reasonably efficiently.
Or by sharing the relevant files for some readers to point to you the source of the issue.
After @FortranFan’s comment, in trying to provide a working (standalone) reproducible example, I came to realise that the memory issue was not IN my part of code (it’s a Library which is then plugged-in into a program), but in their interface/main program side.
I still don’t know which could have been the cause. However, the main issue has been solved.