Memory Magagement Error?

I’ve recently added some automated alerts to my systems, so that whenever a [hdls] entry goes into the diagnostic log: I get an automated alert.
The vast majority of alerts that I’m getting come from my own ON ERR CALL method: I’m doing this:

ARRAY LONGINT($aErr_Codes;0)
ARRAY TEXT($aErr_CompCodes;0)
ARRAY TEXT($aErr_Text;0)
GET LAST ERROR STACK($aErr_Codes;$aErr_CompCodes;$aErr_Text)
$Cnt_i:=Size of array($aErr_Codes)

The [hdls] error is being logged on the last line: where I’m check the size of array:
Error: #52 An array was expected or the type of the array was not appropriate.

It seems to me that at this point: 4D is having some kind of a memory management error: where it can’t allocate ram to create an array.
I’m looking for good advice for

  • 1: Why does this happen?
  • 2: is there any way to prevent this?
  • 3: Once I’m in this situation :is there any way to help 4D to recover within the current process?

4D keeps running (does not crash, fortunately), but the process seems to be stuck.

don’t look like a memory error for me. On a 64 bit system, if an application could not allocate <1kb RAM, then the system is already dead.

Something else must be the source.

I assume it is on the server, so using Info component, and checking that log, could help. It would also prove the question about memory.
If you don’t like info component, you could at least call get memory statistics regularly yourself and log those values.

Also the diagnostic log could help.

If both fails, please contact tech support for analyze

I would not jump to the conclusion that it must be a (global) memory allocation problem, but we do have 1 open support case where local arrays suddenly starts to throw all sorts of errors.

According the customer, it only happens on a persistent (as in a daemon) process or worker on the server. Size of array is used to check the size, yet INSERT IN ARRAY says “out of range”. Also, process variables including OK and ERROR become Undefined for that process, at least on Runtime Explorer. Interprocess variables are fine. So it seems like defensive coding by Type or Value type is possible. But these are all anecdotal, I have not seen a diagnostic report. Their version is v16.

This happens from time to time in our application too. Using 4D Server v17. Unexplained errors suddenly happen that “just can’t happen” in daemon server processes that have been running the exact same code repeatedly. Restarting 4D Server always solves the problem until it happens again.

We have more than 450 4D Servers out there. About 180 of them are all in our AWS cloud environment which means they all have identical VM configurations. The problem happens with both our cloud 4D servers and with clients on-premises 4D servers.

The trouble is, it doesn’t happen that often. So we’re struggling to get a case where it happens and we have info component running at the time. When it does happen, we put info component on and then it doesn’t happen again on that server whilst we’re monitoring it.

Yes: my issue sounds like what both Miyako, and Keith are describing.
This is in various server “stored procedures”: but the error can happen at any points.
However, I’ve also seen this occationally on what I call a “RoboClient” (a 4D clients designed to perpetually run tasks: some call this a “batch workstation”)

The vast majority of my hdls entries is this issue.

This is happening for me as well. Using 4D Server v17.4. I have this same issue happen in background processes on the server as well as web processes. It happens once or twice every few weeks.
Always the the same error of “An array was expected or the type of the array was not appropriate” and the line refers to a local array. Usually a longint array.
I know it is not a memory issue. We track free memory on the server pretty closely.
I am glad that others are having the issue as well.

OK, so we finally got a 4D Server with Info Component running have these errors. I think the Info Component was also affected, so I can’t say how good the data collection will be.

Anyway, the memory usage (SVG) chart from the Info Component reports looks fine across the “problem”. I don’t know what else we can do to track this down.

Currently I’m considering having daemon processes self re-start into a new process every day or something like that, to at least try and mitigate the problem.

Other than that, I’m at a loss as to know how to proceed with this ongoing problem.

I recommend to open a TAOW case. Upload the report folder from the component. Please the complete folder for a longer time period, not only one report. As more reports, as easier it is to see a pattern (or be sure there is none).

Hi Thomas

OK, will do.

Many thanks

Hi

TAOW case 144179 created and reports zip file uploaded

Best regards

Keith

OK, so our reports do include the detection of 2 runtime error windows on 4D Server at the time of a “problem” happening.

It isn’t a memory shortage problem (confirmed by SVG chart of reports), it would seem.

4D Tech support are still investigating, but so far are unable to reproduce the problem (perhaps not so surprising given the intermittent nature of the problem in question).

I’m wondering if the problem is that the process(es) have somehow been aborted or “lost?” by 4D with executing code still in progress, thus clearing local and process variables/arrays.