I noticed today that my application closes, without any error message, when I open a certain number of table browse windows, all of them with a START instruction.
For example, I open 1, 2, 3… and after a while, when I open the 7th one from the menu, the application suddenly closes for no reason.
Does anyone know how to fix this or what could be causing this issue? I noticed today that my application closes, without any error message, when I open a certain number of table browse windows, all of them with a START instruction.
For example, I open 1, 2, 3… and after a while, when I open the 7th one from the menu, the application suddenly closes for no reason.
Sometimes it happens even just by opening menus.
Does anyone know how to fix this or what could be causing this issue?
This could be due to many problems.
One less obvious issue is that there might be some difference between calling a procedure in a DLL that returns a value and one that isn’t explicitly included.
Maybe take a look at task manager and see if you might be approaching 2GB of memory in the process? If so, maybe LARGE_ADDRESS in your .EXE’s .EXP file would help use a bit more memory (up to around 3GB).
In .exp file, LARGE_ADDRESS doesn’t show up.
I don’t know how to add it, because when I compile, it disappears from the file. No .exp file, LARGE_ADDRESS doesn’t show up.
I don’t know how to add it, because when I compile, it disappears from the file.
The amount if memory each thread consumes drpends a lot in the amount of yhreaded data in the app.
The obvious culprit here is the number of tables. And while the number is part of it, the sum if record buffers comes into play. Plus of course there are threaded FileManager objects for each thread and so on.
A typical file record is maybe 2k large. 600×2k =1.2 megs. BUT memos are also included, do if you make extensive use of memos uou need to factor that in.
There is more than just the record overhead per table. But even if we add a lot there we’re a long way from 600 megs.
So i suspect you have one, or more, global threaded objects in play. You might want to take a look in your app.clw file to see if you have ,Thread and what those things are. Pay particular attention to anyhing there are a lot of, or any custom threaded objects that might gave a large data space.
To get more info on an EXE that shuts down with no message look in the Windows Event Viewer.
In the Tree under Windows Logs look in Applications for your EXE closing. It will probably have a Red or Yellow icon. The details may provide you some help. The log entries for your EXE from before the crash may help.
I tried to summarize my test involving a data DLL and an EXE.
Honestly, I tried several things and I wasn’t successful.
Bruce, you mentioned the app.clw file. I’m sending(not sure if I should) ss000.clw (data DLL) and teste5.clw (EXE) in case you can help me. I don’t know exactly what I’m supposed to do.
I’m in a big mess, because from my ERP—with several DLLs and EXEs—I ended up creating a standard version with only one EXE, and this EXE has been closing very frequently.
jobcard, very thanks
Should I put it in the app .exe, right? I did that, but it keeps closing the same way.
With every START, the private bytes increase considerably, and when it gets close to 1700 MB, the .exe closes.
Yes. I just put it in my app.exe.
I think your issue sounds as though it’s more than a large address issue.
I’d follow the advice the others have given looking for global threads.
cheers
Rohan
Lisandro. Take a look at the in-memory tables with ‘/THREADEDCONTENT’ that are created only for each thread. Those tables don’t have the thread attribute. I don’t know how that combination works, but it seems to be the most likely cause.
A simple way to see if memory consumption is reduced is to remove “bindable” from in-memory tables that do not need it.
