Not enough memory for CreateWindow()

[Thomas_cim]

Hello out there,

we've got a brand new and very annoying OpenROAD Problem.

We have a OpenROAD Program which runs under a service, so it has the Service-Window Station, and Session 0.
So far, so good. The funny part is that we use normal OpenROAD Programs which show many Windows, but because of the Service-Session they are not visible to anyone on the server (even on the console).
For a wonder this works. And this works fine. Most of the time - but now we got a non repeatable problem from time to time -> CreateWindow(ScroolBar) fails with error 8.

If we can believe Microsoft (and we have no other choice than doing so) this error (ERROR_NOT_ENOUGH_MEMORY) means 'Not enough storage is available to process this command'.

Now the question to me is: What kind of memory talks Microsoft of ?
We have a memory limit of 2000 MB per Process in Windows - is that one meant ?
Or maybe GDI-Object Limits ? (This one is 10.000 per Process and 65.000 Computer-wide).
Or maybe USER-Object Limits ? (also 10.000 per Process / 65.000 Computer-Wide)
Or maybe handles ? But I don't think that we really exhaust 16.000.000 handles (which are the maximum per process).

To me it seems that OpenROAD reaches the 2 GB Memory Limit.

Next step will be to get procump to generate a memory dump of w4glrun.exe when it's memory raises above 1 GB - but thats not so easy ...

Any comments ?
Am I on the wrong way ?

Thomas

[Thomas_cim]

... I've tried to reproduce the error 8, but had no luck.
(I'm using openframe in a loop, after opening 54 huge Frames OpenROAD closes)

When OpenROAD reaches about 1,1 GB of Private Bytes it simply closes.
No error in Trace-File:

Window 53 from 100
-I- cdfr_4580_02 -> kz_no_matrix_in_kalk: 1
-I- cduc_mengeneinheit::read()
Window 54 from 100
-I- cdfr_4580_02 -> kz_no_matrix_in_kalk: 1
-I- cduc_mengeneinheit::read()
Window 55 from 100
-I- cdfr_4580_02 -> kz_no_matrix_in_kalk: 1
-I- cduc_mengeneinheit::read()

[Brigitte]

I think it is a combination of different parameters see for example GDI Objects.

I am not sure what you mean by 'huge' frame? Lot of visual objects, lot of data (example array with numerous rows) lot of line of code, ...?
Anyway depending on where in our internal OpenROAD code we will have reach the limits for the process, we either trap it and are able to put a message in the trace or we exit.

For example I just created a frame 10x10 buttonfields in a matrix, and I call this frame in a loop. Depending on the machine where I am running it I can see the CreateWindow error in the trace, or OpenROAD just exit because it fails on some other API or when it needs to allocate more memory.

So now why are you reaching the limits with your application? May be we have some memory leaks in OR, may be the 4GL application is loading lot of data (example Tablefields with lot of rows).

Is this always happening at the same place in your code you may be able to identify the component generating the error and check the system resource at that time?

It seems you are running batch so I am confused on the fact you are running frames?

[Thomas_cim]

Hello Brigitte,

great that you also answer questions in the forums and not only on the support line :-)
(this seems to be our error and so I don't open any case ...)

GDI-Objects can be the problem, but I really don't know by now.
I've raised GDIQuota per Process frmo 10.000 to 50.000 - maybe it helps.

My 'huge' frame has many visual objects (tabfolders, tablefields), much arrays and about 6000 Lines of (processed) code.
Every openframe of this frame needs 20 MB Memory.
After 55 times opening it (and leaving every frame open !) we crash with 1,1 GB Private Bytes in the w4glrun-Process.
Some kind of error-message would be great in this case.

The next I try is to use perfmon to check the system the whole weekend (because this kind of batch runs over the weekend).
Maybe I see some clues.

And after that I'll configure procdump as a runtime debugger, generating a crash dump when a w4glrun-process exceeds 800 MB of Commited Memory.
With this crash dump I can see the Stacktrace, searching through the memory and maybe finding out what wents wrong ...

(The Problem with this case is that it happens, let's say, when we calculate article 'A' over the weekend, it fails with the CreateWindow()-Error.
Calculating article 'A' the next day just works fine - so it has to be something to do with the load of the machine ... maybe...

And showing frames in batch-processing is some kind of odd, but it was the easiest way to get a foreground process to background.
Simply adding some 'bool_automatic' and so letting OpenROAD itself fill all entry fields and pushing the OK-Buttons in the background.

I'll keep you informed, and if you have any ideas, fell free to tell them to me :-)

Greetings from rainy germany,

Thomas

[Thomas_cim]

Just a quick update.

The batchrun was this weekend and had no problems - Unfortunately :-(

On the attached image you can see one of the runs. Green is the CPU-Time, Purple is the Memory-Size the process uses.

Nothing to see ...

Thomas

PS: The purple line looks a little bit like a heatbeat :-)