forums.silverfrost.com

[Ryan]

I'm trying to replace some C++ bridge code that opens a file dialog using an .exe and I'm calling the code below but it is crashing reliably.

This is in 64 bit.

If I add CALL CLEARWIN_OPTION@("alt_open_save") then I can get it working.

Is this still the recommended way to open a common dialog box natively from SilverFrost Fortran or am I missing something?

It seems very unreliable without the extra option which is not obvious.

[PaulLaidler]

Ryan

Yes you are on the right track but it is not usually necessary to use alt_open_save.

alt_open_save has the effect of loading the common dialog box in an external process and this in turn fixes an obscure Microsoft issue.

My impression is that the Microsoft issue relates to a lack of available memory. This would explain why it is intermittent since it then depends on the amount of physical memory available and the size of the folder structure that is being accessed.

[Ryan]

Thanks Paul,

I'll do some more investigations but it is not behaving consistently between 32 and 64 bit.

[Ryan]

It seems between 32 and 64 bit there is no single solution. I'll have to use #ifdef unless you have any suggestions.

Findings;

32 bit, no flag = Does not allow changing directory for ~30 seconds, then does a little bit and then stops again. Unstable.

32 bit, alt_open_save = Works, but does not remember previous dir.

32 bit, -alt_open_save = Does not allow changing directory for ~30 seconds, then does a little bit and then stops again. Unstable.

64 bit, no flag = Works fine and remembers dir.

64 bit, alt_open_save = Crashes with log noted as 1 below.

64 bit, -alt_open_save = Multiple 'Fatal error!' message boxes as log 2 below.

Log 1:
Silverfrost 64-bit exception report on C:\xxxx.exe Thu May 25 13:25:27 2023


Unknown exception (80010012) at address 7ff94535536c

Within file KERNELBASE.dll
In RaiseException at address 6C
In RpcRaiseException at address 50
Within file RPCRT4.dll
In RpcRaiseException at address 14
In HSTRING_UserUnmarshal64 at address 53C
Within file combase.dll
In NdrClientCall3 at address 99E
Within file RPCRT4.dll
In Ordinal147 at address 388C
Within file combase.dll
In ObjectStublessClient32 at address 7E62
In Ordinal87 at address 1A66
In DllGetClassObject at address 9D95
In DllGetClassObject at address C053


RAX = 00007ff945aafbd6 RBX = 0000000080010012 RCX = 0000000049be4fff RDX = 000000000000000f
RBP = 000000004997f408 RSI = 00007ff946881338 RDI = 0000000004af5501 RSP = 000000003d39eb60
R8 = 000000003d39ef40 R9 = 000000003d39e574 R10 = 00007ff945aafb62 R11 = 000000003d39ea00
R12 = 0000000000000000 R13 = 000000003d39edb0 R14 = 000000004997f408 R15 = 000000000000000e

7ff94535536c) db 0f,1f,44,00,00

Log 2:
"Exception @1a01b478: Access violation, Silverfrost exception handler has failed" and similarly but address @8819f1. Plus about 8 others.

[Kenneth_Smith]

This look very similar to the error Robert was asking about concerning select_printer@. While I could replicate that problem, it did not persist after the next windows update. Might be worthwhile checking that the windows installation is upto date. The referenced dlls are part of the operating system.

Your code runs OK on my machine.

[Ryan]

I'm always up to date, so it's not that. It looks like memory corruption / buffer overruns to me.

Even the 64 bit version is not stable now.

I've figured out that the original developer had the out of process C++ window dialog for a reason. I think they hit all of these bugs over a decade ago.

[PaulLaidler]

I think that the results may vary with the operating system and from one machine to another.

If you want a fix for "32 bit, alt_open_save = Works, but does not remember previous dir" then I could probably look into that.

[Ryan]

I've found the 64 bit is unstable too so I'll look at patching the C++ app for now.

Thank you.

[DanRRight]

While i have typically many issues with my programs but notorious get_filtered_file@ or similar Open/Save/SaveAs/Close files in %eb work last 15 years without any problem at all. Now in Linux Mint+Wine they still work ok. Somehow my devilry punishment mixed me up with somebody else and decided to harass me with Linux where i already broke 3 Linux installations

May be the length of names and maximum number of files is important for get_filtered_file@ work properly?
I see that in one case which never failed at all i used 128 characters for the file names, and maximum 1600 files as a limit in the directory (who cares? Take any large numbers, memory is cheap now. Though i a bit forgot how all that works). Now i would try 256, 320 or even 512 for the length of filenames.