Ease handling of "not enough memory" problems...

[GerdW]

Problem: 

When handling larger data blocks I get "not enough memory" error messages with only option to kill the executable (from time to time, but usually unwanted ).

Most of the time this involves array functions (initialize array, build array, etc). As this problem is also related to the used PC it cannot be tested (easily) on a developer machine before deploying the executable to a wide range of computers...

I propose the idea to enable some error handling in such cases. This could be done in two ways:

1) Add error output to array functions. This could be available optionally by right-click menu so you don't break older code. Output would be an error stating "Not enough memory for operation ..."

2) Add a new application event "Application.MemoryAllocationError". This way the program the program can atleast catch the problem. (Inspired by "OnError" constructs of text-based programming languages...)

[GerdW]

To illustrate way 1) I add a picture of an ADD node: this one already changes it's look when a waveform is to be added. Here also error-in/-out terminals appear. This could be done for other functions as well...

[Jannis]

Yes, we definitely need a solution to the "not enough memory"-problem! It's to embarrassing to deliver the new software and get a phone call the application stopped with no hint to where, why and how much to big.

I guess the reason for not having an error wire for that yet is the difficultly to locate the spot where it happened. In my case your "add-Error" won't suffice since I'm running out of memory when reading large image files. (build array)

So I'm voting for solution (2) and want an extra event.

[X.]

There is a recent discussion that ended up getting to this suggestion as well (with a disappointing feedback from NI to say the least).

[SteenSchmidt]

I'd be happy for some sort of error output that just could tell if an allocation failed. Not if the requested allocation is possible (since that'll create a racing condition), but attempt the malloc and then report to me if it failed so I can retry the operation using a less memory-demanding algorithm. It could be a handful of special prims in the Memory Control palette for instance (Init Array, Build Array and a few cousins). Wouldn't really work for real-time as this is far from deterministic, but it might save the day for some applications that would otherwise just run head first into the "insufficient contiguous memory" wall.

Cheers,

Steen

[Arlon]

This is a particular problem on RT targets like the cRIO. Program crashes with no feedback and no way to log the event - lots of fun to debug. In my case, it was a TCP read that was trying to read too many bytes (due to a previous read which returned erroneous data without throwing an error - but that's another story).

[X.]

It seems to me that a backward compatible way to address these issues (without having to introduce new primitives with error in and out connectors) would be to have a callback event that could be handled in a Event Loop (similar to "Panel Close").

You could then choose to analyze the problem (Source, other parameters gracefully provided by the runtime engine) or ignore it (as would be the case currently).

There is probably a lot of caveats with this concept, but I could live with somethign like that, if it could be implemented.

In fact, I would argue that the same should be possible with any error that is not handled in the code (unconnected error out, and options below left unchecked)