Crashes and CPU overload while fetching long history (>500 messages)

[churik]

User Story

As a user, I want to see all messages fetched correctly and I could use app (switch to profile, add new contacts etc.) simultaneously.

Description

Type: Bug

Summary: reproducible with last status-go develop branch (#5001). When you join public channels with 7-day history > 500 messages (i.e., #status) then:

1. application hangs or crashes
2. StatusIm CPU Usage ~99-102 %

IMPORTANT NOTE: can be reproducible with chats with 50-100 messages when you switching between chats during fetching messages or when you add new chat and switch to it when messages are not fetched yet. Not 100 % but I faced with it already 10+ times.

Expected behavior

app is responsive

Actual behavior

application hangs, then crashes

Reproduction

• Open Status
• Join channel with history > 500 messages in 7 days (i.e.#status)
• Try to scroll message history or switch to profile; pay attention to CPU usage.

Additional Information

• Status version: PR-5001
• Operating System: MacOS High Sierra

Logs

• NOTE: after crash you should manually exit ubuntu-server process an restart app to continue.
• Full StatusIm log:
  StatusIm.log

Process:               StatusIm [13208]
Path:                  /Users/*/Downloads/*/StatusIm.app/Contents/MacOS/StatusIm
Identifier:            StatusIm
Version:               0
Code Type:             X86-64 (Native)
Parent Process:        ??? [1]
Responsible:           StatusIm [13208]
User ID:               502

Date/Time:             2018-07-03 12:47:20.048 +0300
OS Version:            Mac OS X 10.13.5 (17F77)
Report Version:        12
Anonymous UUID:        93B7A170-78AE-1670-E0DF-EF45503C77C4

Sleep/Wake UUID:       5C4FB9E8-003B-4AC9-BA2D-C421DA3DB707

Time Awake Since Boot: 110000 seconds
Time Since Wake:       21000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  CrBrowserMain  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x00007fcf953ffff8
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [0]

VM Regions Near 0x7fcf953ffff8:
    MALLOC_SMALL           00007fcf93800000-00007fcf95000000 [ 24.0M] rw-/rwx SM=PRV  
--> 
    MALLOC_TINY            00007fcf95400000-00007fcf95800000 [ 4096K] rw-/rwx SM=PRV  

Thread 0 Crashed:: CrBrowserMain  Dispatch queue: com.apple.main-thread
0   libsystem_platform.dylib      	0x00007fff6ac7e169 _platform_memmove$VARIANT$Haswell + 585
1   StatusIm                      	0x0000000108c228ce 0x108bbf000 + 407758
2   StatusIm                      	0x0000000108c225a9 YGNode::insertChild(YGNode*, unsigned int) + 41
3   StatusIm                      	0x0000000108c14c5d YGNodeInsertChild + 125
....

full log

[churik]

Same crash is reproducible if you are switching between 3 different public chats with different message history (1 day, 2 days, 3 days)
Video: http://take.ms/cdUQq
Build: reproduced on desktop, build 11

Monosnap screenshot tool

File "screencast 2018-07-05 19-33-39.mp4"

Monosnap — the best tool to take & share your screenshots.

[maxhora]

Reopen the issue since crashes still happens

[maxhora]

Update:

High CPU overloading issue on scrolling of long chat history is resolved by ScrollView optimization.

Most of known crashes still have the source in uimanager::manageChildren method which triggers call of YGNode::insertChild where the assert and crash appears.

Crash happens (in known cases), because on adding of new Child node into yoga layout that new Child node already has another parent set. It's important to find out the core reason which breaks the logic.

[maxhora]

Since flow to report crashes is implemented ( #5425 ) and number of crashes experienced by users is much decreased for now, going to move this Issue from the board.
Probably, it should be closed for now as well. cc: @churik