retepetab
commented
8 months ago Still having SC3 crashes and appears to be when flying longer than 60 - 80 minute flights. Flights less than that works ok.
Closed retepetab closed 1 month ago
retepetab
commented
8 months ago Still having SC3 crashes and appears to be when flying longer than 60 - 80 minute flights. Flights less than that works ok.
GenericNerd
commented
8 months ago Can you please provide your smartCARS log for this issue?
retepetab
commented
8 months ago Hi
Where do I find this on MacOS Sonama
thanks
Peter
On 26 Oct 2023, at 1:59 pm, GenericNerd @.***> wrote:
Can you please provide your smartCARS log for this issue?
— Reply to this email directly, view it on GitHub https://github.com/invernyx/smartcars-3-bugs/issues/352#issuecomment-1780339803, or unsubscribe https://github.com/notifications/unsubscribe-auth/AW7OSI3U57U7Y4TSSYO3SPTYBHGZJAVCNFSM6AAAAAA5VCZSLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBQGMZTSOBQGM. You are receiving this because you authored the thread.
retepetab
commented
8 months ago I think these are the files you require.
This is a new flight EGKK to LOWI of just over 2 hours, SC3 crashed 2/3rds through flight.
SC3 3.1.1 Flight Tracking 1.0.6 Flight Center 1.0.4
On 26 Oct 2023, at 1:59 pm, GenericNerd @.***> wrote:
Can you please provide your smartCARS log for this issue?
— Reply to this email directly, view it on GitHub https://github.com/invernyx/smartcars-3-bugs/issues/352#issuecomment-1780339803, or unsubscribe https://github.com/notifications/unsubscribe-auth/AW7OSI3U57U7Y4TSSYO3SPTYBHGZJAVCNFSM6AAAAAA5VCZSLKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBQGMZTSOBQGM. You are receiving this because you authored the thread.
 {\rtf1\ansi\ansicpg1252\cocoartf2757 \cocoatextscaling0\cocoaplatform0{\fonttbl\f0\fnil\fcharset0 HelveticaNeue;} {\colortbl;\red255\green255\blue255;} {*\expandedcolortbl;;} \paperw11905\paperh16837\margl1440\margr1440\vieww11520\viewh8400\viewkind0 \deftab560 \pard\pardeftab560\slleading20\pardirnatural\partightenfactor0
\f0\fs26 \cf0 -------------------------------------\
Translated Report (Full Report Below)\
-------------------------------------\
\
Process: smartCARS 3 [2236]\
Path: /Applications/smartCARS 3.app/Contents/MacOS/smartCARS 3\
Identifier: com.electron.smartcars-3\
Version: 3.1.1 (3.1.1)\
Code Type: X86-64 (Translated)\
Parent Process: launchd [1]\
User ID: 501\
\
Date/Time: 2023-11-02 11:51:38.6901 +1100\
OS Version: macOS 14.0 (23A344)\
Report Version: 12\
Anonymous UUID: 51A6E745-CE8E-5D14-8141-5D3CA5D4939F\
\
\
Time Awake Since Boot: 8100 seconds\
\
System Integrity Protection: enabled\
\
Notes:\
PC register does not match crashing frame (0x0 vs 0x7FF89286AA78)\
\
Crashed Thread: 0 CrBrowserMain Dispatch queue: com.apple.main-thread\
\
Exception Type: EXC_CRASH (SIGABRT)\
Exception Codes: 0x0000000000000000, 0x0000000000000000\
\
Termination Reason: Namespace SIGNAL, Code 6 Abort trap: 6\
Terminating Process: smartCARS 3 [2236]\
\
Application Specific Information:\
abort() called\
\
\
Error Formulating Crash Report:\
PC register does not match crashing frame (0x0 vs 0x7FF89286AA78)\
\
Thread 0 Crashed:: CrBrowserMain Dispatch queue: com.apple.main-thread\
0 ??? 0x7ff89286aa78 ???\
1 libsystem_kernel.dylib 0x7ff8024807a6 __pthread_kill + 10\
2 libsystem_pthread.dylib 0x7ff8024b8f30 pthread_kill + 262\
3 libsystem_c.dylib 0x7ff8023d7a4d abort + 126\
4 Electron Framework 0x1197880e2 node::Buffer::New(v8::Isolate, char, unsigned long) + 182450\
5 Electron Framework 0x1197882f8 node::OnFatalError(char const, char const) + 504\
6 Electron Framework 0x113ab3170 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate, char const, v8::OOMDetails const&) + 704\
7 Electron Framework 0x113ab310d v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate, char const, v8::OOMDetails const&) + 605\
8 Electron Framework 0x113c6bced v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) + 4429\
9 Electron Framework 0x113c472a5 v8::internal::Factory::AllocateRaw(int, v8::internal::AllocationType, v8::internal::AllocationAlignment) + 613\
10 Electron Framework 0x1126f9846 v8::internal::FactoryBase
retepetab
commented
7 months ago any advice for a fix - still crashing in less than one to one and a half hours - SC3 will not stay running for me any longer than that.
GenericNerd
commented
7 months ago Seems like there is a crash for the process being out of memory. What is your RAM and disk space?
tinroof
commented
5 months ago Hi, I believe this bug is also being experienced on a Linux machine running Manjaro Gnome. I have been intermittently experiencing the client crashing to desktop mid flight. Initial thought was a limit on time/distance flown however this assertion has not panned out. I did begin noticing that CTD was likely to occur when the interface is obscured via fullscreen youtube and/or moving and remaining in another desktop leaving the client off screen. Upon return and exposing the client canvas the crash is likely to occur.
To try and trap some further info I ran the client from within GDB debugger. I then flew numerous flights with the client tracking each. Initial two were fine as I intentionally kept the client interface exposed. On a third flight whilst tracking the flight I spent 45+ minutes in another desktop depriving the client interface exposure. After returning to the client desktop and initiating interaction with the client the client froze and was unresponsive. GDB recorded stdout suggesting JS is experiencing a lack of heap memory. It further suggests that Garbage Collection may be influencing this. Below is an exerpt;
<--- Last few GCs --->
[7042:0x14440065c000] 40688769 ms: Mark-Compact (reduce) 2973.2 (3022.4) -> 2973.1 (3005.4) MB, 83.29 / 0.00 ms (average mu = 0.994, current mu = 0.311) last resort; GC in old space requested
[7042:0x14440065c000] 40688861 ms: Mark-Compact (reduce) 2973.1 (3005.4) -> 2973.1 (3004.7) MB, 92.93 / 0.00 ms (average mu = 0.983, current mu = 0.000) last resort; GC in old space requested
<--- JS stacktrace --->
FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Thread 1 "smartCARS3" received signal SIGABRT, Aborted.
```--------------------------------------------------------------------------------------------------------------------------------
Anyone know if Garbage Collection is affected by a lack of interface exposure?
Thought this info might be useful. Naturally I will attempt to verify this in subsequent sessions in the next few days.Hi,
Have done a load of trial flights that I have attempted to track with SC3. I am now convinced the CTD has no relation to the client being obscured or operating on an inactive desktop . I now have to agree with the assertion of "retepetab" and that it is related to the time the client tracks a flight.
I have undertaken multiple sets of testing using X-Plane 12 on linux. The first two were of most significance. Both ran SC3 client under GBD so output text could be obtained when a CTD is encountered. Obervations suggest GDB was unnecessary and that simply executing from a terminal is likely to have accomplished the same.
The first was with Concorde flying between NZAA and YBBN. Three attempts were flown. The first flight CTD at about 115mins with the entire cruise phase on an inactive desktop. A second flight similarly conducted with SC3 client on main desktop and was interacted with when it too CTD at 105 mins. A third flight was then flown however for this flight once the aircraft was at cruise X-Plane's x2 acceleration (ALT-T) applied until TOD then the remainder of the flight conducted at normal speed. SC3 successfully tracked and recorded the PIREP. This flight took a little under 60mins.
Each CTD output the messages I have included in my previous post. For this reason I have not included them here.
My second set of tests did not attempt to examine the relationship between CTD and the client's canvas exposure. It primarily concentrated on tracking time. A long flight YPDN-YSSY in A320 following the exact same routing and altitude. The flight takes 4 hrs to complete. Attempt 1 CTD prior to 2 hrs. Attempt 2 undertaken at 4x acceleration during cruise. CTD at TOD 100 mins flight time Attempt 3 undertaken at 8x acceleration during cruise. Flight tracked to completion and PIREP filed. Duration 79mins.
Two VFR flights over a flight duration of 80mins were tracked and PIREP filed. The flights were conducted with differing routes and aircraft.
It should be noted the way X-plane employs acceleration is by multiplying out the aircraft speed. The acceleration has no affect on the passing of simulated time or the simulation speed itself.
The CTD is repeatable simply by tracking a flight over a duration exceeding about 100 min. So much so I have no intention of attempting to track a flight with a duration likely to exceed 90 mins using SC3 until this bug has been eliminated.
atanneberg
commented
5 months ago I totally agree with tinroof - you can observe in the activity tracker that SC3 consumes more and more RAM until it consumes all free RAM of the given machine and as soon as memory swapping starts SC3 crashes. No relation to different planes or locations - just pure runtime related crash as far as I can see. Starting SC3 from the terminal does not change this behaviaour.
retepetab
commented
3 months ago Thank you atanneberg and tinroof for your diligence in trying to ascertain why we have this problem. I consider myself reasonably tech savy but it was beyond me. I run a Mac Studio M1 Max with 32 gb memory have no problem with other programs, hopefully there will be an update to SC3 to fix this problem and allow us to fly more than very short flights.
GenericNerd
commented
3 months ago @atanneberg @retepetab Here is my response in issue #374 which is similar to this:
Per @Thien42's recent testing, we can confirm that there is a memory consumption issue which appears to only be present in MacOS. This is important since the same increase in memory consumption is not present in Windows or Linux under similar steps to reproduce.
With this being said, we believe there is an issue with a memory leak in one of our dependencies specifically on MacOS (the most likely being Electron). We'll keep this thread up to date as there are developments.
Describe the bug
SC3 again crashing to desktop. Upgraded to SC3. 3.1.1 Was working ok then approx half way through a 2-15 hr flight it ctd SmartCars3 Crash 6Oct3023.txt
attached is the Apple crash report - all circumstances are the same as #348 except O/s is now Ventura 13.6
How do you reproduce this bug?
Flight of 2-15hrs I did complete a 51 minute flight previously which completed with no problem
Expected behavior
No response
Screenshots
No response
Operating system
Mac Ventura 3.16
Community airline
Q Virtual
smartCARS Version
3.1.1
Plugins installed
Flight Centre 1.0.4. Flight Tracking 1.0.5
Additional context
No response