Can't see values in allocated arrays in debugger

[David_DiLaura1]

I'm working with a large engineering application with multiple large allocated arrays. In a effort to keep as much of computation in RAM as possible (avoiding the Page File), the arrays are allocated and deallocated repeatedly within loops. After adding a few more allocatable arrays I can nolonger view the contents of the allocatable arrays in the debugger: not in the Immediate Window, not in mouse-over, not in Quick View, and not in Viewer. I know that the correct values are in the arrays, as the computations are correct, and if I do something primitive, like write(6,*) values to the screen, the values are displayed correctly. The allocatable floating point arrays usually show a true zero or a number that is clearly not a valid 4-byte float. The allocatable integer arrays nowusually show random integers in the debugger.

I'm running W XP SP2, Studio 2003. This happens with 9.1.034 and 9.1.037. Any thoughts?

David DiLaura

[Steven_L_Intel1]

We've had some issues in this area in the past, though 9.1.037 should have addressed most of them. Please put together a small (if possible) example showing the problem and attach a ZIP of the project to an Intel Premier Support request for assistance.

[Jeffrey_A_Intel]

A question and a comment:

You say "After adding a few more allocatable arrays I can nolonger view the contents of the allocatable arrays in the debugger..." Does that mean that before you added "a few more allocatable arrays"you could viewthe array contents?

My comment is that allocatable arrays are no more or less likely to stay in memory that any other data in your application. All writable memory pages arecandidates for being movedto the page filewhen the demand for memory is high. Obviously, a "good" systemwill attempt tokeep frequently accessed pages in memory but there are no guarantees.

[David_DiLaura1]

Jeff,

Yes, there appears to be some threshold of the number and/or size of allocatable arrays-- afterwhich I can't view the contents of allocatable arrays. Interestingly, if I change the code and make one of the arrays 'fixed', then I can always view the contents of that array. The problem is only with allocatable arrays; I have had no trouble with fixed arrays -- however large.

About memory: what I'm doing is trying to keep the program's total memory request below a level that forces the OS to start using the page file. That's why I'm allocating and then deallocating arrays.As a practical matter (for W XP, at least) once I step up the totalmemory request, much of the program's memory accesses generate HD thrashing and (naturally) unhappily long execution times.

[Jeffrey_A_Intel]

I think Steve's suggestion is the best approach then. If we can reproduce the problem, we have a chance to findthe problem.

I understand now what you're trying to accomplish with all the allocatable arrays: limit the peak memory usage so that paging doesn't occur. As long as the overhead of all the allocating/deallocating doesn't hurt, that's fine.

[jimdempseyatthecove]

David,

Depending on the version of the O/S and the C Runtime System the heap allocation is either First Fit or Least Recently Used/Never Allocated(or other schemes). LRU was put in as a bandaid fix for crappy programs that would access memory _after_ returning it tothe free pool.

Your description of your allocation method it would seem you are expecting First Fit. Which may not be the case. If the heap manager is LRU and if your allocations and deallocations are somewhat random what will happend is initialy in the program what fits in X megabytes of RAM will later require 2X megabytes of RAM. Or potentially worse (using fractional page in RAM)

Also, it sounds like you are using the Array Visualizer (a favorite of mine). If AV is called very frequently (like I do) then you will notice a slow memory leak (PF usage creaping up). My "fix" for that was to add a button to a dialog box that I use for controlling my simulator. Clicking the button launches a new instance of the Array Visualizer. This gives me 2 features for the price of 1. If memory runs low I can the Array Visualizer (or kill it with Task Manager). Then wait a bit while watching the PF usage. When memory returns, I click on the button to launch a new instance of AV. While this is all happening the simulation continues to run.

The second feature of this technique is I can launch a 2nd viewer. Then I can watch a 3D plot of the simulation as it runswhile using AV in the second instanceto look at tables while the simulation is running. I can also add ad-hoc plots on the fly. 2D plots are relatively easy to add by hand.

Too bad Inteldidn't see the value in AV.

Jim Dempsey

[Intel_C_Intel]

david.dilaura@colorado.edu:

I'm running W XP SP2, Studio 2003. This happens with 9.1.034 and 9.1.037. Any thoughts?

Hi,

Side question: Just three days ago I've got an email from Intel about the latest IVF compiler for Windows version 9.1.036 which I downloaded and installed.

Is there a 9.1.037 version for download?

Thanks,

Yair

[Steven_L_Intel1]

9.1.037 is available. 9.1.036 was announced a couple of weeks ago - it was intended to be released at the beginning of March but it had issues that needed to be resolved. 037 is back on our usual schedule, though I understand this can be puzzling to have two releases so close together.

If you are a Professional Edition customer, you may need to wait until Monday or Tuesday to see 037 at the Intel Registration Center.