Welcome to our forums
John, Just a thought - When you try to identify the problem with a cut down program - does it work? If so, try using the cut-down program as a stand alone spawned from the main program and communicate via files or messages. Use an always_on_top to hide the fact. Ian PS, I'm probably talking rubbish - again.
This is really astonishing. I use get_filtered_file@ since many years in many programmes, now under Win 7 with 32 or 64 bits, and all times without any problem. I have no idea whether we can find a solution by comparing the relevant parts of our codes? I always use set_open_dialog_path@ just before calling get_filtered_file@ - could it be that this avoid problems? No idea...
Regards - Wilfried
I have compared the 2 programs I noted previously and now managed to get the one that was not working to work by reducing the memory footprint. I have a large array to store information (pre ALLOCATE days). This was set to : integer4, parameter :: million = 10001000 INTEGER4, PARAMETER :: MXSTOR = 260million INTEGER*4 IIBASE(MXSTOR)
The program works for 200m and 260m but fails for 300m and 360m. The memory usage (from the .map file) for 260 gives the hex address : 4cb7f000 end Linker defined
260m > 1,228 mb works on windows 7 300m > 1,381 mb fails on windows 7 360m > 1,609 mb fails on windows 7 works on XP
As I am using Windows 7_64, the next test could be to try ALLOCATE to move the large array above address 2gb and see if it still works.
I have shown that by changing the memory layout (below 2gb) that the program operation changes. Based on this I would estimate that the routines that get_filtered_file@ calls is overflowing the memory requirement and clashing with other memory usage.
( To explain my interpretation; changing the size of common changes the size of section .bss in the link map. This shifts around in memory (0-2gb) a number of system allocations that are not listed in the .map. Changeing from 1.2gb .bss to 1.6gb .bss squashes up these system allocations and probably results in the memory corruption. Not sure when these system allocations are made. Could be at link time or at run time. While modifying the size of the stack or heap might change the performance, I have never been successful using this approach. )
This is possibly why some programs work and others do not in Windows 7.
A patch may be to reduce the size of .bss. If using Win7_64 you have access to 4gb of memory. This might be achieved by using ALLOCATE and shifting large arrays into the 2gb-4gb memory area. You can test this by using l = loc (array) and declare l as integer*8 to report memory addresses above 2gb.
The best solution is to update the API calls and remove this problem.
John
ps: my memory management equivalences real4, integer4 and logical*4 arrays for sharing the memory. If anyone knows how to reproduce this using ALLOCATE and modules, I'd like to know.
! Last change: JDC 7 Aug 2009 3:03 pm
! INCLUDE sapcom.ins structure variables
!
integer*4, parameter :: thou = 1000
integer*4, parameter :: mill = thou*thou
INTEGER*4, PARAMETER :: MXSTOR = 360*mill ! maximum storage available (I*4) in XP
!
COMMON /SAPCM9/ AABASE ! memory buffer
REAL*4 AABASE(MXSTOR)
INTEGER*4 IIBASE(MXSTOR)
LOGICAL*4 LLBASE(MXSTOR)
EQUIVALENCE (AABASE,IIBASE)
EQUIVALENCE (AABASE,LLBASE)
!
Has anyone tried reducing memory to solve this problem ? Having a memory usage report from the load map somewhere between 1,228mb and 1,381mb load map appears to solve the problem and is consistently working for me. It would be good to know if it works in other cases also.
John
On my second call to get_filtered_file@ the routine returns immediately with a blank filename - it will not even open the dialog box.
So far, I think there is only one sure way to overcome the problem, as far as I can tell, and that is to overwrite an existing file. So, copy a file with the correct extension into the destination folder and rename it to the target name and select it from the dialogue, then when you click 'Save', the 'do you want to overwrite' prompt appears and the dialogue completes successfully.
K
Paul,
To improve the performance of GET_FILTERED_FILE@ in Windows 7, would it be possible to provide an alternative version (say GET_WIN7_FILTERED_FILE@) as a wrapper for the API functions from the recommended Common Dialog Box Library to see if this changes the performance. I am not sure of the functionality difference, but my understanding is we need a pop-up dialogue to select and open a file. My present understanding of the problem is that it can eat a lot of the stack. My coding response is to limit my graphics program to about 1.3 gb when I use /DEBUG.
John
GET_FILTERED_FILE@ and GET_MULTIPLE_FILENAMES@ should default to the new Vista-style Open file dialog under Windows Vista and Windows 7.
This is because the internal ClearWin+ call to GetOpenFileName does not use the hook and template members of the associated OPENFILENAME structure.
This should mean that an adaptation of these routines for Window 7 should make no difference. In other words, we will need to add a dummy hook or template to the internal code in order to opt for the old style dialogs when running under Vista or Windows 7.
Please let me know if this is not the case.
Paul,
I'm confused again. My earlier impression of reading the MSDN documentation was we have to change to the Common Item Dialog API. I assumed that all the problems with get_filtered_file@ locking up on Windows 7 was as this is not happening. In past testing, if I increased the amount of memory my program uses to above 1.3gb, then it starts locking when trying to select a file. When the new version of the compiler arrives and I can use ALLOCATE for above 2gb with /debug, then I'll try and see if this changes the problem. I note no one has commented on this for a while, so perhaps they have found a solution?
John
Hi John/Paul
The problem I was having seems to have been 'reduced' (without me changing anything!). I've had some Windows Updates since my last test so perhaps MS have fixed it?
If it comes back, I'll let you know!
K
edit. This was updated a couple of months ago - might this have fixed it?
http://support.microsoft.com/kb/2640148
K
It's back! In a nastier form...
If I call get_filtered_file@ to retrieve a file name, an ALLOCATE call much much later on fails. If I just hard code the filename instead of using get_filtered_file@, then the ALLOCATE doesn't fail and the program runs to completion.
So, something must be screwing something somewhere, but what and where, I have no idea. It's unlikely to be reproducible in a Noddy, as the ALLOCATE that fails has been called multiple times before it fails...
Where do I start looking?
First up, I'll try under XP32 and W7-32 and report back...
K
edit: works under XP32, not under w7-32...
K
Kenny,
What is the memory usage size for this program ? I found the error was sensitive to this. I was wondering if this was the case generally ?
John
Hi John,
Total memory usage for the app peaks at about 980Mb when it runs successfully, but when it fails, it's at about 750Mb. I can 'stress' the otherwise successful method by adding extra 'malloc' calls. If I do, it fails at about 1Gb - is this a physical limit for PCs anyway?
Some more information may put the focus back on it being a MS problem...
I have 3 ways of accessing the file browser dialogue: FTN95, Qt and C++ DLLs and they all exhibit the same problem. The C++DLL calls the 'XP-style' version and the QtDLL calls the 'Vista-style' so, I think the problem is that calling that dialogue at all puts a 'ceiling' on the amount af memory that ALLOCATE can get at?
K
Kenny,
My app fails at above 1,300mb but works ok below that. From your size estimate of 980mb, it would appear that memory size is not a reliable indicator. I have written a subroutine to find the 16 biggest vacant memory locations. I can run it at different times, releasing all (most) the memory at each call. It could be used to map available memory around the get_filtered_files call. I'll try it around my get_filtered_file call and see if I can identify lost memory. This problem looks like a bug in windows interface to libraries. Not sure if it's the new version or the old interface.
One day a fix will come.
John
Hi John,
I'm using the 'peak private bytes' stat from Process Explorer, is that what you used?
K
Here's a 'noddy' that illustrates the problem:
!ftn95$free
Program Memtest
WINAPP
INTEGER i,winio@,open_func
EXTERNAL open_func
CHARACTER*10 :: COP
KOUNT = 0
IBFSZ = 40*1024*1024
WRITE(*,*) 'Call file browser (Y/N)?'
READ(5,'(A)') COP
IF( COP.EQ.'Y' .OR. COP.EQ.'y') THEN
i=winio@('%ca[Image info]&')
i=winio@('%mn[&File[&Open,E&xit]]',open_func,'EXIT')
END IF
DO
CALL GET_Storage@(IAD, IBFSZ)
IF( ABS(IAD).LE. 100) EXIT
KOUNT = KOUNT+1
END DO
WRITE(*,*)'Allocated: ', KOUNT * (IBFSZ/1024/1024),' Mb'
END
INTEGER FUNCTION open_func()
INCLUDE <windows.ins>
CHARACTER file*129,format*12,title*20,path*129
INTEGER NFILTERS
PARAMETER(NFILTERS=2)
CHARACTER*20 filtname(NFILTERS),filtspec(NFILTERS)
title='Open Bitmap File'
file=' '
path='c:\\windows'
filtname(1)='Bitmap files'
filtspec(1)='*.bmp'
filtname(2)='All files'
filtspec(2)='*.*'
CALL get_filtered_file@(title,file,path,filtname,filtspec,NFILTERS,1)
open_func=1
END
Various results, depending on the slink switch:
With /3Gb: Don't open file browser: 2960Mb Allocated Say 'Y' to prompt but then select file-->exit on dialogue: 2960Mb Allocated Open file browser: 1920Mb Allocated, regardless of whether a file is opened...
Without /3Gb Don't open file browser: 1360Mb Allocated Say 'Y' to prompt but then select file-->exit on dialogue: 1360Mb Allocated Open file browser: 360Mb Allocated, regardless of whether a file is opened...
Someone on the MS developer forum has offered to investigate but wants source in C/C++ - Paul, can you provide that?
K
Paul,
There is definately a problem with get_filtered_file@, as it's use limits the amount of memory available. My impression is that the API routine being used has the problem as it has a problem with memory leakage.
The MSDN documentation for 'GetOpenFileName' indicates that:
[Starting with Windows Vista, the Open and Save As common dialog boxes have been superseded by the Common Item Dialog. We recommended that you use the Common Item Dialog API instead of these dialog boxes from the Common Dialog Box Library.]
Is this recommended approach available from the FTN95 routine or could it be made available ?
We should test both alternatives to see if either does not produce the memory leakage problem.
John
John
Please see my last comment in this thread.
The Common Item Dialog approach is the default for the appropriate operating systems. This is what you get with get_filtered_file@ for the reasons stated.
Kenny
When I get back to my office I will see if I can put together an independent C program that illustrates what happens in the library.
Hi John,
I think that get_filtered_file@ IS now calling the new dialogue (at least, it looks like the new one, with my 'favourites' and 'libraries' in the LH panel) - so I think the issue is with MS, but we need to have a C/C++ version of the 'memtest' program above to prove it.
K
edit: see Paul's reply at the same time!!!! 😃
If we are now using the new file open dialogue and getting the memory leakage, is it possible to revert back to the old file open dialogue and see if the problem goes away ? It would probably loose access to the new library addressing features of Windows 7, but I'm yet to take advantage of this.
I havn't tested Kenny's example above, but it may be a useful vehicle to test an old and new file open dialogue box approach.
Now that /debug works with /3gb, the memory limit might be overcome, providing an effective solution to the limited memory.
John