- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I am trying to use the latest Intel Fortran compiler (17.0.1.143). My program compiles fine but when I run the Debug version (I didn't try the Release version), I get a C++ RTL error:
Debug Error! Damage before (some memory address) which was allocated by aligned routine.
The error is occurring at two locations:
1. When I call a function that returns an array of user-defined data type that includes ALLOCATABLE array attributes. I was able to fix this by converting these functions to subroutines.
2. When I try to DEALLOCATE an array of user-defined data type that includes ALLOCATABLE array attributes. Maybe I should first deallocate the attributes before attempting to deallocate the array?
This code worked fine with 16.0.4.246 and earlier versions of the compiler. Can this be an issue with the compiler? Any help will greatly be appreciated.
Thanks!
EDIT: For item 2 above, it turns out that the error occurs if one of the array arguments of the user-defined type is not previously allocated. I use the STAT argument with DEALLOCATE to avoid checking if an array is allocated before deallocating it. This has always worked in the past.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Interesting. Thank you for your post. We recently received another reported sighting of this message, https://software.intel.com/en-us/forums/intel-visual-fortran-compiler-for-windows/topic/705024.
Development is still investigating this earlier case. It would really be instructive to us if you could provide a complete reproducer for your case that covers both locations you noted. Is that possible?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Unfortunately, I can't replicate the issue with a simple program. The original code includes several levels of user-defined types (UDT) being used for array arguments in other UDTs. I will have to submit the original code to the premier support.
However, digging into this a bit more, I discovered that the deallocation issue in item 2 above is also related to the constructor being coded as a FUNCTION. When the constructor is converted to a SUBROUTINE, I don't have any issues with deallocating the array arguments of the variable.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page