I’ve come across the following discussions about 4GB memory limitation due to Electron:
I have written a custom analyser to decode the IS25LE QSPI commands. This seems to work well and correctly however the software is randomly crashing in a similar fashion to the other posts.
I am currently on 2.4.13 which I believe is the custom version of Electron without the 4GB limit.
Here is the crash report that I am receiving from Logic2:
Crash reporting enabled. Machine ID: 139f57b3-b65b-41ab-aeba-89c75a507e85
[1558164:0221/112022.066073:ERROR:gpu_memory_buffer_support_x11.cc(44)] dri3 extension not supported.
[1558164:0221/112030.124279:ERROR:gl_utils.cc(319)] [.WebGL-0x562763026b60]GL Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels
[1558164:0221/112030.193312:ERROR:gl_utils.cc(319)] [.WebGL-0x562763026b60]GL Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels
[1558164:0221/112030.243711:ERROR:gl_utils.cc(319)] [.WebGL-0x562763026b60]GL Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels
[1558164:0221/112030.267476:ERROR:gl_utils.cc(319)] [.WebGL-0x562763026b60]GL Driver Message (OpenGL, Performance, GL_CLOSE_PATH_NV, High): GPU stall due to ReadPixels (this message will no longer repeat)
@saleae/electron/main: renderer process died { reason: 'crashed', exitCode: 133 }
sendToFrame() failed: Error: Render frame was disposed before WebFrameMain could be accessed
Attempting to call a function in a renderer window that has been closed or released.
Function provided here: bundle.js:872:5498
Is there any additional testing I can do to test that this is indeed the issue? Or is there another fix that I can try?
Thanks!
I tried debugging the thread with gdb and I’ve attached the log here:
saleae_gdb_log.txt (44.6 KB).
I think of interest is the exception:
Thread 95 "StreamDatabase:" received signal SIGTRAP, Trace/breakpoint trap.
[Switching to Thread 0x7f819085d700 (LWP 3022570)]
0x0000562767ee9fcf in ?? ()
(gdb) bt
#0 0x0000562767ee9fcf in ?? ()
#1 0x00007f819085c210 in ?? ()
#2 0x00000000bc800000 in ?? ()
#3 0x00007f819085c0f0 in ?? ()
#4 0x0000562767ee9fe9 in ?? ()
#5 0x00007f819085c110 in ?? ()
#6 0x0000562767f64e58 in ?? ()
#7 0x7fffffffffffffe6 in ?? ()
#8 0x000056276bdd2150 in ?? ()
#9 0x00007f819085c140 in ?? ()
#10 0x0000562767f64a3e in operator new(unsigned long) ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) c
Continuing.
[Thread 0x7f81aa7fc700 (LWP 3023887) exited]
[Thread 0x7f819786b700 (LWP 3023877) exited]
[Thread 0x7f819bb7f700 (LWP 3023889) exited]
[Thread 0x7f819906e700 (LWP 3023876) exited]
[Thread 0x7f824ffff700 (LWP 3022481) exited]
[Thread 0x7f819886d700 (LWP 3023881) exited]
[Thread 0x7f81a903b700 (LWP 3023888) exited]
[Thread 0x7f823cff9700 (LWP 3023886) exited]
[Thread 0x7f823e7fc700 (LWP 3023884) exited]
[Thread 0x7f824f7fe700 (LWP 3023883) exited]
[Thread 0x7f823d7fa700 (LWP 3023885) exited]
[Thread 0x7f81daffd700 (LWP 3022250) exited]
[Thread 0x7f82b9ffb700 (LWP 3023882) exited]
Thread 95 "StreamDatabase:" received signal SIGILL, Illegal instruction.
0x0000562767ee9fcf in ?? ()
(gdb) bt
#0 0x0000562767ee9fcf in ?? ()
#1 0x00007f819085c210 in ?? ()
#2 0x00000000bc800000 in ?? ()
#3 0x00007f819085c0f0 in ?? ()
#4 0x0000562767ee9fe9 in ?? ()
#5 0x00007f819085c110 in ?? ()
#6 0x0000562767f64e58 in ?? ()
#7 0x7fffffffffffffe6 in ?? ()
#8 0x000056276bdd2150 in ?? ()
#9 0x00007f819085c140 in ?? ()
#10 0x0000562767f64a3e in operator new(unsigned long) ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
A lot of these functions seem to be in your binaries so I don’t know if there is much more I can do here
@haydn.reysenbach Thanks for sharing all of the details you’ve provided thus far regarding this error. We’ve experienced the GPU stall due to ReadPixels error in the past when the analog and digital channels struggle to draw. After toggling channels on and off, we were able to get the digital channels to display some of the time, but we weren’t able to get the analog graphs to render. Ultimately, we found this is due to GL errors. We came across this error when running the software inside of a VM with 3D acceleration disabled.
I’m not quite sure what to make of the gdb log yet. Thanks for sending that over though! I’ll pull in our software team next time I get a chance to meet with them.
I do have some follow up questions for you.
- What Linux Distro are you running?
- Are you running inside of a VM and/or with 3D acceleration disabled?
- Are you experiencing the same crashes when using any of our pre-installed protocol analyzers? I’m wondering if the issue is mainly only noticeable with your custom analyzer.
- Have you noticed a pattern as to when the crashes occur? Is it consistent? Also, since you brought up the 4GB limit issue, is it specifically crashing when you reach approximately 4GB of memory usage, or did you primarily bring up that forum post due to the similarity of the error message?
@timreyes Ah that does make a bit more sense then. For your questions:
- We are currently using RHEL 8. I know it is unsupported but it is the only distro that we can use and run all of our other tools on too.
- We are running it as a VM with 3D acceleration disabled
- I have only been using the SPI analyser and that does not crash on the same trace
- There is some sort of pattern because the SW will always crash when processing a part of the capture. Previously I had the capture include 3 transactions and it would crash while processing the third. I sliced them into individual captures and it would only crash on the capture of the third transaction (which makes sense as the third transaction is the longest). However it did not get any further in the capture when processing the samples. In other words there seems to be part of a trace that will always cause the crash but the sample number changes between runs.
I could not really see any other posts which matched my error except for those so they were my main suspects. Also given that it crashed while processing a certain part of the capture but at a different sample made me suspect that it was a memory limitation.
I did check the memory usage while debugging with gdb and it is indeed greater than 4GB (I think around 8GB if I recall correctly) so I think we can eliminate that issue.
To me it looks like the main culprit would be the VM without 3D acceleration. Do you know what the solution was for that?
I am also rewriting my analyser using the SPI analyser as a base and will try and test with that instead. I’ll let you know the results when I complete it.
Thanks for the response 
Hello Tim,
Just a quick update for you. I finished the rewrite using the SPI analyser as a base and I’ve found that it works now with no changes to the VM.
I’m more than happy to help you guys debug this further if you want but I think I will continue my work with this new analyser.
Thanks for your help
1 Like