Got this message upon saving: Saving scenario failed: The mod Utilization Monitor (Blargh) (0.8.3) caused a non-recoverable error.
Please report this error to the mod author.

My PC has about 8 GB of free memory while running Factorio, or at least after restarting.
Relevant bit of the log:

Error while running event UtilizationMonitorBlargh::on_save()
bad allocation
18951.519 D3D11_ERROR: ID3D11Device::CreateTexture2D failed in createInternalTexture on line 243. Error [0x8007000e] - E_OUTOFMEMORY
18951.519 > TextureDesc: Width=1920, Height=1080, MipLevels=1, ArraySize=1, Format=45, Usage=0, BindFlags=40, CPUAccessFlags=0, MiscFlags=0
18951.519 Error RenderUtil.cpp:777: take_screenshots failed: Failed to create a texture.
18951.616 Warning WriteFileGuard.cpp:57: Writing C:\Users\Marco\AppData\Roaming\Factorio\saves\1.1 restart - 5 starter oil.zip failed; previous version (if any) should still be available
18951.617 Error ParallelScenarioSaver.cpp:132: Saving scenario failed: The mod Utilization Monitor (Blargh) (0.8.3) caused a non-recoverable error.
Please report this error to the mod author.

UtilizationMonitorBlargh doesn't have an on_save handler, nor anything that would trying to take screenshots or create textures. There isn't even a crazy amount of data being stored in its global variables - less than a kilobyte per entity tracked. What does /umstats show for tracked entity count?

Looking at the above it looks like you may have ran out of video RAM? Not sure why it's blaming a mod function that doesn't exist though, unless maybe it was the last mod?

I added some better cleanup code to 0.8.4, just on the off chance there IS something in the mod causing crazy high memory usage.

Can you post the save that was crashing for you?

Sadly, I can't.
The error prohibited saving, and the save before that was corrupt, so I deleted it. I could recover from an autosave, but that is overwritten now. And after the first three occurrences the error didn't show up anymore, without updating the mod.

So you are probably right that there is an external cause for this error, but memory shortage isn't likely. Playing factorio and having a bunch of browser tabs open, system and gpu memory both rarely hit 60%. I've had Nvidia driver issues on this rig before, so that is my prime suspect.

And lastly: nobody is blaming the mod. Not the game - it simply reports the last know position before things go wrong - and certainly not me.
I thank you for a very useful mod.

No worries, I'm just pondering why UMB showed up at all, purely out of curiosity. I wonder if its something like it's the last mod you have loaded alphabetically or something?

It is not the last mod alphabetically.
The problem still hasn't returned, and I did not update to the latest version just to see if it did.

I have an unrelated question: if the mod tracks more objects than max updates per tick, what happens then? Will it only track the max number, or track all but not update every tick?

The mod internally maintains a list of all objects tracked, which it goes through round-robin. Each tick, it evaluates objects up to the max updates per tick or the length of the list, whichever is lower.

So, if there are 300 objects and max updates is 600, it will process the entire list of 300 objects each tick (it won't evaluate them all twice because of the length-of-list limitation).

If there are 1,500 objects and max updates is 600, it will process 600 of those objects every tick - so it may go #101-#700 in tick 1, #701-#1300 in tick 2, #1301-#1500 and rollover to do #1-300 on tick 3, etc.

The averaging algorithm adapts to the number of samples collected in the past measurement interval (one second) when it calculates and shows the averages for the past N minutes. So the first time an object is looked at in each second (there are 60 ticks in a second), that averaging occurs and the displayed numbers updated.

A bit of a follow up - this is why the warning message that comes up when you exceed the limit mentions reduced accuracy.

If an assembler (for example) is running low on materials, but only for an extremely short time (one tick), the mod will catch that if it's iterating every object every second, but may miss it if it can only look at that one object every other tick or so.

In practice, one of the current games the mod is running on has 5,700+ objects tracked and the max objects per tick set to 600 (because one of the people on the multiplayer server is playing on a potato), and it's generally OK - there are a couple situations I can see with extremely fast belts and loaders that it seems a little off on because of that issue.

Programmer to programmer: deftly done!

Might I suggest an option to forgo the warning?

While I'm at it: I would prefer a ratio setting over a hard number. That way the accuracy doesn't degrade with the size of your base.

Heh, thanks! I will say some of the iteration code was inherited from the old Utilization Monitor mod, although at this point I've refactored a lot of it and added quite a bit.

So the warning only appears once when the limit is first exceeded, or can appear again if the limit is reconfigured and is too low. Basically, once right when the limit is exceeded, and that's it. I view it as a rather minor issue, and the message is just basically an FYI.

The issue with doing a ratio is the UPS hit would get worse as the base grows in size, and for better or worse, UMB is relatively heavy for an on_tick function. I've done a lot of work to minimize it, but Lua is Lua and it's a lot of calls into Factorio data. At least with a hard limit, the UPS hit has an upper cap, at the sacrifice of a little accuracy that most people won't generally notice.