Size of stack affect Windows dialog

Size of stack affect Windows dialog

Hi,

I have a problem calling the Windows function GetOpenFileName() from my program.
What hapens when I call it depends on the stack size I requested.

When I set the size of Linker->System->stack reserve size to

200 M it opens the dialog box and I can sellect a file after about 3 s. (Debug compiled)
300 M the call stals for a while, do not show a dialog box, but returns in about 7 s.
400 M call do not return, I waited at least 60s.

I attach my Win32, Quickwin Project showing this behavior.

I use this call in my OpenMP project and there I need to set a large stack to start/run my program.
Can somone enlighten me if this is a feature, a Windows bug of a compiler bug?
Or am I doing something wrong?

Is there a workaround for the large stack size needed to start my program?

My setup:
Core i7 , 4 GB memory
windows 7 64 bit.
vs2010
Compiling with Intel Visual Fortran Compiler XE 12.0.2.154 [IA-32]...

Regards,Magnus

EDIT:
If i just after GetOpenFileName insert
iret=CommDlgExtendedError()
I get iret=0 for 200M and iret=2 for 300M.
Futher I noticed that for 400M it do return after 140s with iret=2
googling I find at msdn.microsoft.com
--
CDERR_INITIALIZATION 0x0002

The common dialog box function failed during initialization. This error often occurs when sufficient memory is not available.

--

What units are used when setting stack size?

Could I be out of some special sort of windows memory?

AttachmentSize
Downloadapplication/zip QWin2.zip83.11 KB
32 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

I can't reproduce this problem. No matter what I set the stack to (the units are in bytes and the maximum is about 1GB, even on x64), the dialog opens immediately and closes as soon as I click the button. Can anyone else try this?

Retired 12/31/2016

Hello to everyone,

I tried the attached project and I can't see what you described. No problema at all (dialog opens immediately and closes when I click the button). I tested stack sizes from 100mb till 1gb. I'm running Visual Fortran Compiler XE 12.0.2.154 [IA-32] under win7 64bit.

Pedro

Hi,

I now let four of my colleagues download (from the Forum) and run this project and they see the same strange behavior changing with stack size.

We all have Win 7 Pro(English with swedish keyboard) , VS2010 Pro(English), and Visual Fortran Compiler XE 12.0.2.154, but the rest of the spec varies.

Switching to English keyboad and rebooting did not help. Compiled and run inside and outside VS2010.

This beats me. Do anyone have any idea for something for me to test?

Best Regards,
Magnus

Reboot into "Safe Mode" and see if the problem persists. You may have some background software, such as an antivirus product, interfering.

Retired 12/31/2016

Thanks for the idea, but it did not help.

Its strange behaviour persist in Windows "Safe Mode" both running VS2010 as normal user and Administrator. The behaviour is identical for 100m and 200M stack size but for 300M it do not return with an error in several minutes.

Regards,
Magnus

Perhaps you should now post the code that you use to fill the OpenFileName structure for the call to GetOpenFileName? Have you tried running in Debug mode to see what value is used for the structure size?

Hi,

The source code for filling in the OFN structure are seen in Source1.f90 in the project I attached to the first post, was this what you asked for?

The ofn%lStructSize= sizeof(ofn) = 88 in Debug mode.

Here is the content of OFN when calling GetOpenFileName
- ofn {...} TYPE(T_OPENFILENAME)
ofn%LSTRUCTSIZE 88 INTEGER(4)
ofn%HWNDOWNER 0 INTEGER(4)
ofn%HINSTANCE 0 INTEGER(4)
ofn%LPSTRFILTER 14321088 INTEGER(4)
ofn%LPSTRCUSTOMFILTER 0 INTEGER(4)
ofn%NMAXCUSTFILTER 0 INTEGER(4)
ofn%NFILTERINDEX 1 INTEGER(4)
ofn%LPSTRFILE 14321344 INTEGER(4)
ofn%NMAXFILE 256 INTEGER(4)
ofn%LPSTRFILETITLE 14321600 INTEGER(4)
ofn%NMAXFILETITLE 256 INTEGER(4)
ofn%LPSTRINITIALDIR 14321856 INTEGER(4)
ofn%LPSTRTITLE 14320832 INTEGER(4)
ofn%FLAGS 524326 INTEGER(4)
ofn%NFILEOFFSET 0 INTEGER(2)
ofn%NFILEEXTENSION 0 INTEGER(2)
ofn%LPSTRDEFEXT 0 INTEGER(4)
ofn%LCUSTDATA 0 INTEGER(4)
ofn%LPFNHOOK 13308576 INTEGER(4)
ofn%LPTEMPLATENAME 0 INTEGER(4)
ofn%PVRESERVED 0 INTEGER(4)
ofn%DWRESERVED 0 INTEGER(4)
ofn%FLAGSEX 0 INTEGER(4)

Regards,
Magnus

Magnus, do you still have this problem?

Retired 12/31/2016

I have been having these problems as well - see recent thread GetOpenFileName and GetSaveFileName. I'm running on W7 also. I had missed a CloseThread call in a subsequently called thread which seems to have had something to do with this issue BUT the reason that this cured the problem is not clear as the stack size value I had chosen was 100MB, i.e. well below the 2GB limit.

For what it's worth, the stack limit is 1GB on Windows, even on x64.

Retired 12/31/2016

With IVF Composer, VS2005 runnning on 32-bit Windows XP Pro, I have no problem opening and closing the Open File dialog. I note that under Properties..linker...stack reserved size = 300000000 by default, all other entries zero or 'default'.

P.S. I thought that a QuickWin 'main' program thread had to contain a 'do nothing' loop like so:

iret=GetOpenFileName( ofn )

write(6,*) 'File name = ',szfile(1:LEN_TRIM(szfile))

do while(.true.)
call sleepqq(500)
end do
end program

This will leave your seperate main Quickwin thread established after the call to GetOpenFileName. That's the thread that does all the work. That loop is missing from your code.

P.P.S. Although I can confirm that the hook procedure is called and the WM_INITDIALOG message is intercepted, I cannot get the SetWindowPos function to reposition the GetOpenFileName window when I use non-zero X and Y values and change the flags value to SWP_SHOWWINDOW, i.e.

bret = SetWindowPos( hDlg, f2, X, Y, 400, 700, SWP_SHOWWINDOW)

appears to be ignored. The window appears in the default top left corner location always.
Commenting out all your code between CASE(WM_INITDIALOG) and CASE DEFAULT except FileHookProc=1 has no discernable effect.

The reason turns out to be that you should be using

bret = SetWindowPos( GetParent(hDlg), f2, 400, 400, 600, 900, IOR(SWP_NOSIZE, SWP_SHOWWINDOW))

if you want to affect the position of the actual dialog box, which is the parent of the (invisible) child window that receives the hooked message.

Hello,

i can reproduce the problem. But it depends on the windows version.

Using:
- Win XP Prof (German) 32 bit i cannot reproduce (even with higher stacksizes)
- Win Vista Prof (German) 32 bit
---- Stacksize 200MByte the main dialog is openning and notings happens
---- Stacksize 300MByte the main dialog is openning and 5 seconds later the close dialog appears

- Win 7 Prof (German) 64 bit
---- Stacksize 200 MByte GetOpenFileName works witin a second
---- Stacksize 300 MByte GetOpenFileName opens after approx. 5-7 seconds
---- Stacksize 400 MByte the main dialog is openning and 5 seconds later the close dialog appears

The Program is compiled with IVF Version 11.1. and VS 2008 Standard (German). But if i remenber correctly i had this problem with IVF 10.X and VS 2005 Standard (German) too.

I have this problem for a long time. I have devloped a visualisation tool were i need to set the stack to 600MByte.

If any one can find the reason, that would be helpfull.

As fare as i can understand is jansson (Magnus) a user with swedish specifics. I am german. Is there any one in this group with also non english layout? Can he reproduce or not reproduce the problem?

Frank

It's a QUickWin project, No? Have you added the DO WHILE loop as suggested?

Have you tried GetFileNameFromBrowse instead?

Hello,

adding the lines:

do while(.true.)
call sleepqq(500)
end do

using win 7 ...
and the program is lasting at least 1 min without doing anything

adding:
iret= GetFileNameFromBrowse (ofn)
instead of GetOpenFileName

is producing an error.

Frank

Thanks for asking Steve.

I worked around it. I made a few local arrays STATIC, and that was enough to get stack size down to about 15M in my project. Is there another or better way using Open-MP Fortran? But now my program eats allot of memory from the start, it previously did so only while computing.

But prior to this I reproduced it in pure C in vs2010. I think this mean its not a Fortran specific problem, but C users maybe newer use this much stack, I do not know.

A detail: Is this /stack:reserve size the sum of all stacks for all threads in the process? else what entities is it limiting?

Another unimportant detail, under x64 it runs when I set stack to 1500M but not to 2000M.

Best Regards,
Magnus

Hello Steve,

i would like to understand the connection between stack size and GetOpenFileName. Is there a place where i can find a description?

i also can not understand the dependency with the windows version. For my test, listet above, if have used the same exe-file on the different computer.

Thanks in advance
Frank

There is no connection. If the stack size is insufficient, the program will fail with a stack overflow error (or sometimes an access violation). A change in results or behavior due to varying the stack size or Windows version strongly suggests a coding error that is dependent on memory layout.

Retired 12/31/2016

Hello Steve,

i have started a new quickwin projekt. Then i have added the given source code from the original start post. Then i have changed the stacksize. The result i have posted above.

is there an error in the given original source?

Thanks in advance
Frank

Well, you've made things much more complicated than they need to be. You don't need the hook function at all if all you want is your dialog to be on top. Instead, as the compiler-provided sample shows, set hwndOwner to the result of calling GetForegroundWindow().

I have fixed up your source and it is below - it works fine as a QuickWin program.

program main
  use comdlg32
  use user32, only: GetForegroundWindow
  use kernel32, only: GetCurrentDirectory
  use ifport, only: SLEEPQQ
  implicit none
  integer       :: iret,ilen
  character*512 :: curwdir
  character*256 :: title,szfile,szfilter,szFileTitle
  TYPE (T_OPENFILENAME)	ofn


title	   = "Open file"C
szFilter   = "All files (*.*)"C ! NB two NULL are needed at the end
szFile	   = "*.*"C
szFileTitle=""
curwdir=""

ofn%lStructSize		= sizeof(ofn)
ofn%hwndOwner		= GetForegroundWindow()
ofn%hinstance       = NULL
ofn%lpstrFilter		= LOC(szFilter)
ofn%lpstrCustomFilter	= NULL
ofn%nMaxCustFilter	= 0
ofn%nFilterIndex	= 1
ofn%lpstrFile		= LOC(szFile)		! filename with full path returned in szFile
ofn%nMaxFile		= len(szFile)
ofn%lpstrFileTitle	= LOC(szFileTitle)	! filename only returned in szFileTitle
ofn%nMaxFileTitle	= len(szFileTitle)
ofn%lpstrInitialDir	= NULL
ofn%lpstrTitle		= LOC(title)
ofn%Flags		    = IOR( OFN_EXPLORER, IOR( OFN_OVERWRITEPROMPT, OFN_HIDEREADONLY ) ) 
ofn%nFileOffset		= 0
ofn%nFileExtension	= 0
ofn%lpstrDefExt		= NULL
ofn%lCustData		= 0
ofn%lpfnHook		= 0 !LOC(FileHookProc)	! FileHookProc forces dialog to TOPMOST position
ofn%lpTemplateName	= NULL
ofn%flagsex         = 0

ilen=len(curwdir)
iret=GetCurrentDirectory(int4(ilen),curwdir)
ofn%lpstrInitialDir=LOC(curwdir)

iret=GetOpenFileName( ofn )

if (iret .eq. 0) then
  type *,'No file name specified'
else
  ! Get length of file_spec by looking for trailing NUL
  ilen = INDEX(szfile,CHAR(0))
  type *,'Filespec is ',szfile(1:ilen-1)

end if

do
call SLEEPQQ(300)
end do
end program
Retired 12/31/2016

Hello Steve,

thanks a lot for providing the example. But it is not working for me. I have added 3 files as attachments. Two screenshots and my project folder.

Thanks in advance
Frank

Attachments: 

Just to get things clear, you are creating a 32-bit Quickwin Windows application and running it on a 64-bit system?

Have you tried removing the GetOpenFileName call from the Program file that runs in a seperate thread from the Quickwin stuff and activating it from a menu call-back function to see if that works independently of stack size? I do not see the point of having it in the location you choose for it, as any filename selected has no where to go to.

my system has 64bit.

yes this test dummy is in 32bit (most of the users of my programm have 32bit systems)

I have the same probleme working with win vista prof 32 bit

All i looking at , with this test dummy is, does the OpenFile dialog is opening or not.

Using the produced exe-file on a win xp system i have no problem at all

Frank

You are not alone - see this link:

http://social.msdn.microsoft.com/Forums/en-US/windowscompatibility/threa...

It finishes by saying

"This still is not fixed in Vista SP2, BUT it is fixed in Windows 7 RC!"

although your experience would appear to be the opposite.

I also note from here http://www.codeproject.com/KB/vista/VGFileDialogs.aspx#usingwithapis

that

"Using the File Dialogs with Windows APIs

If an app calls the GetOpenFileName() or GetSaveFileName() API to show a file dialog, and does not customize the dialog at all, then Vista will show the new file dialog since there is no danger of breaking the app. The criteria that Vista uses to determine if the app customizes the dialog is whether there is a hook function address stored in the lpfnHook member of the OPENFILENAME struct, or a custom dialog template stored in the lpTemplateName member.

Since MFC and WTL use a hook function to provide notifications to the app, if you use either library's CFileDialog class, you will get the Windows 2000-style dialog. Therefore, to get the Vista-style dialog, you'll need to use the new COM interfaces that replace the GetOpenFileName() and GetSaveFileName() APIs.

"

SO perhaps you should dispense with the hook flag and procedure and try again.

Also check what version of comdlg32.dll is being loaded/required.

Hello,

thanks a lot
for providing the interesting links.

you are writing:
...SO
perhaps you should dispense with the hook flag and procedure and try
again.
Also check what version of comdlg32.dll is being
loaded/required.

To be honest. I do not have any clue how to
do it.

Any help will be appreciated.

----

But be the way. Why is
this not reproducible be Intel (Steve). All I have is a normal (ok
German) installation including all offline updates until February.

Thanks in advance

Frank

My example did not use the hook procedure. You don't need the hook procedure.

Retired 12/31/2016

I can reproduce strange behavior on Windows 7 x64 with the 32-bit program and the 300000000 stack size. I have no idea why it happens, but that is a rather large stack. This happens even if I don't use the hook procedure (which as I say above you do not need.) I don't know what the problem is here, though what I can see is that the call to GetOpenFilename takes a lot of CPU for a while but does nothing and eventually returns.

Retired 12/31/2016

Hello Steve,

for a test dummy a stack
size of 300MByte may be high. If you are working with climate model
simulation results, data sets easily contain data with TeraByte. To visualize those data I need the full range of
possible stack size.

Is this an IVF or a
windows problem? Can this problem be solved?

Frank

Hello Steve,

for a test dummy a stack
size of 300MByte may be high. If you are working with climate model
simulation results, data sets easily contain data with TeraByte. To visualize those data I need the full range of
possible stack size.

Is this an IVF or a
windows problem? Can this problem be solved?

Frank

Definitely not an Intel problem. It may be a Win32 API issue but it's hard to tell. May I suggest that using /heap-arrays (and allocatable variables) is a better choice than a huge stack?

Retired 12/31/2016

Dear Steve,

I am using Intel Fortran Compiler for my application since 2010. I have the same Problem, as mentioned above in the post. It means, if I reserve a very low stack size, e.g. 100Mb, my program works. But If I increase the stack size, then the Programm started, but "GetOpenFileName" has allways Problem. It doesn't let to open the Open Window. Do you have any idea? It is very important for me. But all of my works, which I developed since 2010, depends on this issue!

Looking forward to hearing you!

Cheers,

Akbar

 

Sorry, I have no more information than what is in this thread. You can try reducing the stack size and enable heap arrays (Fortran > Optimization > Heap Arrays > 0) and see if that helps.

Retired 12/31/2016

Leave a Comment

Please sign in to add a comment. Not a member? Join today