"Out of memory" issues - where do I begin?

sdetweil

@ember1205 i spent a year debugging an out of memory that only crashed one version of a module… another ran fine…

one line of code, my code, made the difference… but the problem ‘appeared’ to be a hang , suddenly the UI was dead…
randomnly displaying pics in the background.

not til I added a totally new logging approach did I find the actual problem, which was out of memory, which killed the UI, which made it LOOK hung…

ember1205

In my situation, the UI goes all black and the cursor appears (no mouse or keyboard connected). There’s a generic “out of memory” error entered into the log file. Restarting MM is the only way I’ve found to get it back up and running.

The photo module I’m running is your fork with the more recent changes to allow the blurring of the same image behind the full-view image. Any thoughts on anything that could/should be added to try and capture more in the logs? Is there an increased logging level I could be using in MM itself? Stack traces when it fails? Before it fails? Anything come to mind that might give me a new avenue?

The issue doesn’t seem to appear if I am not using the photo module. But, that could be because the other, more basic modules don’t use resources as intensively. We’ve compared notes on RPi, kernel, build, etc. and not found anything that seems to be materially different with the one exception being the specific image files in use.

sdetweil

@ember1205 i run that module every day all day and don’t see any problem, but… try this

edit MMM-ImagesPhotos.js

add the line shown below

      					img.style.top = result.targettop+"px";                    // line 271
                                        img=null      /// add this line
					// if another image was already displayed
					let c = self.fg.childElementCount;

ember1205

should it be:

img=null;

???

sdetweil

@ember1205 trailing ; is ok either way

ember1205

Updated and restarted the MM process. I will keep the three browsers hitting it and wait and see if it errors out again. Sometimes, this can literally take days while other times it can occur multiple times in an hour.

sdetweil

@ember1205 each browser is loading the images independantly… the server side just returns the list of images once for each

ember1205

So, the extra “stress” isn’t actually stress on the Pi at all?

sdetweil

@ember1205 well, the file system loading of the images will be thru the pi, but nothing else…all the display side is done in the browser (which is where it ran out of memory)

ember1205

Well, it isn’t a LOT of progress, but it’s progress.

It’s still crashing. But I managed to get a core dump. And it says that it’s Electron that’s crashing. The initial output from bt has me a little confused as I can’t tell if it didn’t load the symbol file correctly, or if the info just “unknown”. Here’s what I get from a bt command:

Core was generated by `/home/pi/MagicMirror/node_modules/electron/dist/electron --type=renderer --auto'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0  0x02760514 in ?? ()
[Current thread is 1 (LWP 6298)]
(gdb) bt
#0  0x02760514 in ?? ()
#1  0x027603d8 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Not really sure if there’s anywhere to go from here. :/