Approximatrix Forums — Memory changes in newest version? (v32.1)

Re: Memory changes in newest version? (v32.1)

null@example.com (jeff) — Mon, 29 Nov 2021 12:56:57 +0000

Pete,

Is there any chance you can send the project to support@approximatrix.com to see if I can replicate the issue? Upon closer reading, I'm not sure it's related to OpenMP. I'm quite confused how referencing segments of an array would cause problems suddenly.

If you're unable to send the source code, could you at least send along the ".prj" file? I'd like to at least replicate your project's options verbatim.

Re: Memory changes in newest version? (v32.1)

null@example.com (jeff) — Sat, 27 Nov 2021 22:06:55 +0000

My guess is that the OpenMP library is mis-calling a Windows API somewhere that wasn't an issue until Windows 11. I'll sort what's happening.

Re: Memory changes in newest version? (v32.1)

null@example.com (peter.kelly) — Fri, 26 Nov 2021 23:47:32 +0000

Hi Jeff,
I was on v3.20 but .... my machine did upgrade itself to Windows 11 during this time.

Re: Memory changes in newest version? (v32.1)

null@example.com (jeff) — Fri, 26 Nov 2021 16:40:14 +0000

Pete,

Could you tell me what platform you're on? Is it Windows?

While nothing should have changed from 3.20 -> 3.21, there might be issues with our Windows-specific OpenMP implementation that might be causing problems with the compiler. However, that would only manifest itself moving from a version earlier that 3.20. Do you know what version you had been using?

Memory changes in newest version? (v32.1)

null@example.com (peter.kelly) — Thu, 25 Nov 2021 01:54:16 +0000

Hi Jeff,
I'm wondering if changes were made in the way memory is handled/allocated in the latest release. I have a test harness to time sorting algorithms against large array data sets (2x10^6 elements). Some of the sorts use OpenMP too.
I used to compile and link the program using absolutely vanilla makefile generated from the options within the project - nothing special placed in there, just nominating optimization options and a "-fcheck=all" flag.
The program used to run a treat, no issues. When I recompiled it with NO code changes, it ran but threw a segmentation violation on any subroutine that used OpenMP.
So, I just commented out the call to the routines that used OpenMP and recompiled. It then threw segment violations wherever I called a routine with an array segment ie. call sort1(Mydata(1:50)) which it never did before.
So, commenting those subroutine calls out + OpenMP using routines, it ran.
I then upped the amount of sort data to (4x10^6) which had been a value that I could use. I recompiled and attempted to run the program and it silently dies before executing any code - despite the compilation working without any warnings.
The code does not throw any memory access violations other than the segment violation.

Is there a difference in mem handling in the new version or a different default stack size set?
Regards,
Pete