I have been dealing with intermittent crashing in our Electron application for the last month and have not been able to arrive at a solution. Crashing causes the Electron window to turn blank because the renderer process is dead but the main process is still alive.
Crashing doesn't seem connected to any particular user action. The app lasts about half an hour on average, but could crash after only 5 minutes or run for a couple hours.
Our stack is pretty standard, with React, Redux, and Sagas.
Here is the exception from the crash dump:
In crash-43.dmp the assembly instruction at node!v8::internal::IncrementalMarking::RecordWriteSlow+1187 in C:\Users\Motorized Precision2\Desktop\mpstudio\node_modules\electron\dist\node.dll from Node.js has caused an access violation exception (0xC0000005) when trying to read from memory location 0x0000000b on thread 0
and the stack trace:
node!v8::internal::IncrementalMarking::RecordWriteSlow+1187
node!v8::internal::StoreBuffer::StoreBufferOverflow+1786
node!v8::internal::CancelableTaskManager::TryAbort+25f
electron!GetHandleVerifier+9e849
electron!IsSandboxedProcess+22d87e6
electron!IsSandboxedProcess+22d7a36
electron!IsSandboxedProcess+22d58b4
electron!GetHandleVerifier+9e849
electron!GetHandleVerifier+47367
electron!GetHandleVerifier+45dba
electron!GetHandleVerifier+a0e86
electron!GetHandleVerifier+4283e
electron!IsSandboxedProcess+3b4634
electron!GetHandleVerifier+3463da
electron!GetHandleVerifier+3462cf
electron!GetHandleVerifier+f6d68
electron+116365
electron!IsSandboxedProcess+2cd4efb
kernel32!BaseThreadInitThunk+14
ntdll!RtlUserThreadStart+21
I have examined the renderer code very carefully to make sure that all listeners/timeouts are handled, and now I'm honestly just not sure what to do next. Is this a memory leak, or something else? Someone save us!
Related
I ran into a problem. If I just run the application through AS, then everything works fine. It enters everywhere, everything opens, all functions are performed. As soon as I try to start Profiler, the application crashes immediately after being turned on. I went to the log and noticed something like this:
Fatal signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x10 in tid 5156 (HeapTaskDaemon), pid 5141 (d.myapplication)
Perhaps someone came across and can tell how to solve this problem.
I have a C++ application on Mac OS X. The app runs an event processing with the glfw library on the main thread and reads input and execute commands on a background C++ std::thread.
I am observing a frustrating phenomenon that I cannot explain so far.
If I make a call to a long running function on the background thread, initially that thread is using 100% of a core. But, after it has used a few seconds of CPU (10 seems to be the magic threshold), it gets throttled down to 25%.
If I start a computation run on a thread in the background before starting the glfw event processing loop (the event processing is essentially stuck waiting for events, as I don't even open a window), then it can use 100% for as long as it wants.
My biggest problem is that I have no idea what could be causing this nor how to figure it out. I've tested retrieving the pthread sched_param and changing the sched_priority from what seems to be default 31 to various values between 20 and 60 and it does not help.
I have identified one more condition for the phenomenon to happen:
The background thread has to have read from the terminal. It happens when I run the following background thread and enter a line for the computation to take place:
std::thread cmd([argc, argv, &scriptingRunner] {
for (std::string line; std::getline(std::cin, line); ) {
longComputation();
}
Perhaps App Nap is throttling your application to save energy. To check, open the Activity Monitor program and right-click on the header of the processes table to bring up the context menu, and click on "App Nap" in the context menu to enable the App Nap column; then look at your process in the table and see if its value in the App Nap column switches to "Yes" when the fault occurs.
If you want to disable app nap for your app, see the code listed in the question here.
My co-workers and I have written a node.js application. I was assigned to debug an issue this week. The issue is that the application crashes every few days with this error:
events.js:0
(function (exports, require, module, __filename, __dirname) { // Copyright Joy
^
RangeError: Maximum call stack size exceeded
Unfortunately it doesn't print anything else.
What node.js methods and tools could I use with node.js to debug this issue? Our application is really huge (it powers the entire campus document finder) so we don't know where this error is happening exactly (there are many files of source code).
From your description (that it crashes, predictably, every few days -- presumably after the same amount of time), it sounds like there may be a thread whose stack is growing over time through recursion. To see this, I'd wait for a day or so and then use ProcDump to force a core dump of whatever container application is actually executing the javascript. Open the core file up in something like WinDbg and look for the thread with the ridiculous number of stack frames -- that could shed some light on your problem.
If you have no tools, create one. You should count function calls by values, I mean you should insert something like this inside the function:
function(...) {
callCounter[module]++;
console.log("module:",module,"count:",callCounter[module]);
...
callCounter[module]--;
} // fn()
Yes, it will flood the screen, (EDIT:) so you may capture it. (This half sentence disappeared somehow, re-added days later.)
I have a MonoTouch application that has an annoying bug and I don't know how to go about resolving it. The problem seems to occur when the application has been in the background for a considerable amount of time (a couple of hours, for example) and then you return to the application. Upon returning from the background, the application will work for a short period (about 10 seconds) and then it freezes up completely and none of the tabs, buttons, etc respond. After another 10 seconds or so, the application is killed by iOS. In the crash log, I see the following reported:
<appname> failed to resume in time
The annoying thing with this bug is that it never seems to occur when I am testing with the debugger; I run the application in debug mode and test it for ages without any problem. I also send it to the background and return without any problem. So, so far it only seems to occur when the application has been in the background for a long time... and it happens at different points in the application, never the same point. Does anyone have any idea what could be happening and how I would go about debugging a problem like this? Thanks.
Your app is probably doing something that takes longer than 10 seconds when you come back from background. iOS forces you to return within that predetermined period, or it'll kill your app for "misbehaving".
Your computer is thousands of times faster than the device. That's why you only see the issue in the simulator.
I would check your AppDelegate class to see what's happening in the WillEnterForeground method, that could be taking so long.
I am devloping a mobile game..In that i got out of memory Exception in exit when playing multiple times..Some of friends said it is due memory allocation so clear the memory.. i clear all the memory allocated for tiled layer, sprite etc at each and every level as well as while exit..
I stop the Thread also at the time of exit. I am handling the Thread to stop in two ways that is given a boolean value in while within the run method and in exit change the boolean value to false and next one before exit calling the thread.interrupt and make a thread to null..
it is hard to tell where the problem is but I suggest to use a memory profiler to catch the problem, Java ME SDK has one and the Nokia S40 emulators also have a very powerful profiler.