Uploading large .aac broke sync?

[PAK90]

I'm using v0.47.5 and out of curiosity I tried uploading a ~150mb .aac file to one of the notes; it seemed to fail the upload and crash the app, but when I re-opened it I found a 'successful' .aac note attached as a child. I could play it and it worked fine. However, I noticed the sync was unable to complete, and the server crashed with a JS memory heap error.

After a few server reboots, this is what I see in the server when it starts up:

DB size: 180940 KB
Note cache load took 388ms
App HTTP server starting up at port 8080
{
  "appVersion": "0.47.5",
  "dbVersion": 183,
  "syncVersion": 20,
  "buildDate": "2021-06-25T21:26:48+02:00",
  "buildRevision": "0a2807c0b3fb7809d1cd1be3a051d127db010b5e",
  "dataDirectory": "/home/pi/.local/share/trilium-data",
  "clipperProtocolVersion": "1.0"
}
CPU model: ARMv7 Processor rev 3 (v7l), logical cores: 4 freq: 1500 Mhz
Listening on port 8080
Slow query took 1391ms: SELECT * FROM note_contents WHERE noteId = ?
Returning 1 entity changes in 4889ms
Slow 200 GET /api/sync/changed?lastEntityChangeId=31188 took 9939ms
304 GET /api/setup/status took 7ms
Table counts: notes: 2198, note_revisions: 1786, branches: 2209, attributes: 6394, api_tokens: 0
Slow query took 23ms: SELECT attributeId, attributes.noteId FROM attributes LEFT JOIN notes USING (noteId) WHERE attributes.isDeleted = 0 AND notes.noteId IS NULL
Slow query took 95ms: SELECT noteId FROM notes JOIN note_contents USING (noteId) WHERE isDeleted = 0 AND isProtected = 0 AND content IS NULL
All consistency checks passed (took 353ms)

It won't crash again if left alone, but if I hit the sync button it gives the Process exceeded time limit 5000 error. Is there an easy fix for this?

[zadam]

Hi, could you post the JS memory heap error?

Is it possible that there isn't simply enough RAM? Trilium needs enough RAM to read the whole file into memory (with some overhead).

[PAK90]

I think this is what showed up at one point:

20:26:24.664 ERROR: get /api/sync/changed threw exception: Error: Failed to allocate memory
    at fromStringFast (buffer.js:427:12)
    at fromString (buffer.js:456:10)
    at Function.from (buffer.js:306:12)
    at ServerResponse.send (/home/pi/Downloads/trilium-linux-x64-server/node_modules/express/lib/response.js:189:22)
    at ServerResponse.json (/home/pi/Downloads/trilium-linux-x64-server/node_modules/express/lib/response.js:267:15)
    at ServerResponse.send (/home/pi/Downloads/trilium-linux-x64-server/node_modules/express/lib/response.js:158:21)
    at apiResultHandler (/home/pi/Downloads/trilium-linux-x64-server/src/routes/routes.js:76:13)
    at /home/pi/Downloads/trilium-linux-x64-server/src/routes/routes.js:117:21
    at Layer.handle [as handle_request] (/home/pi/Downloads/trilium-linux-x64-server/node_modules/express/lib/router/layer.js:95:5)
    at next (/home/pi/Downloads/trilium-linux-x64-server/node_modules/express/lib/router/route.js:137:13)
20:26:37.502 304 GET /api/setup/status took 8ms
20:26:37.621 200 POST /api/login/sync took 6ms
20:26:39.519 Slow query took 1495ms: SELECT * FROM note_contents WHERE noteId = ?
20:26:42.916 Returning 1 entity changes in 4893ms
20:26:46.692 ERROR: get /api/sync/changed threw exception: Error: Failed to allocate memory
    at fromStringFast (buffer.js:427:12)
    at fromString (buffer.js:456:10)
    at Function.from (buffer.js:306:12)
    at ServerResponse.send (/home/pi/Downloads/trilium-linux-x64-server/node_modules/express/lib/response.js:189:22)
    at ServerResponse.json (/home/pi/Downloads/trilium-linux-x64-server/node_modules/express/lib/response.js:267:15)
    at ServerResponse.send (/home/pi/Downloads/trilium-linux-x64-server/node_modules/express/lib/response.js:158:21)
    at apiResultHandler (/home/pi/Downloads/trilium-linux-x64-server/src/routes/routes.js:76:13)
    at /home/pi/Downloads/trilium-linux-x64-server/src/routes/routes.js:117:21
    at Layer.handle [as handle_request] (/home/pi/Downloads/trilium-linux-x64-server/node_modules/express/lib/router/layer.js:95:5)
    at next (/home/pi/Downloads/trilium-linux-x64-server/node_modules/express/lib/router/route.js:137:13)

edit: just saw one now, this just happened out of the blue:

Slow query took 1311ms: SELECT * FROM note_contents WHERE noteId = ?
Returning 1 entity changes in 4680ms

<--- Last few GCs --->

[4355:0x2f96ab0] 83037554 ms: Scavenge 413.6 (448.7) -> 413.2 (455.2) MB, 21.9 / 0.0 ms  (average mu = 0.993, current mu = 0.963) allocation failure 
[4355:0x2f96ab0] 83037632 ms: Mark-sweep 413.2 (455.2) -> 221.3 (237.9) MB, 78.7 / 0.1 ms  (average mu = 0.986, current mu = 0.968) last resort GC in old space requested
[4355:0x2f96ab0] 83037725 ms: Mark-sweep 221.3 (237.9) -> 221.3 (236.4) MB, 92.9 / 0.1 ms  (average mu = 0.965, current mu = 0.000) last resort GC in old space requested


<--- JS stacktrace --->

==== JS stack trace =========================================

Security context: 0x3a67ca41 <JSObject>
    0: builtin exit frame: byteLength(aka byteLengthUtf8)(this=0x5b400299 <Object map = 0x4ae56185>,0x4363e639 <Very long string[202092059]>,0x5b400299 <Object map = 0x4ae56185>)

    1: fromStringFast(aka fromStringFast) [0x46c34785] [buffer.js:424] [bytecode=0x48d296dd offset=7](this=0x21240279 <undefined>,0x4363e639 <Very long string[202092059]>,0x5b400299 <Object map = 0x4ae56185>)
    2: fromSt...

FATAL ERROR: CALL_AND_RETRY_LAST Allocation failed - JavaScript heap out of memory
Aborted

[zadam]

Yeah, so it looks like the process doesn't have enough memory.

[PAK90]

That's odd... I've been running it on my Raspberry Pi 4 for over a year without any issues until now? It only started once I tried uploading this .aac file. If I start up the server again now and hit sync in the client, it still says it's exceeded 5000 milliseconds...

[zadam]

Yes, the crashing started after you uploaded the AAC file. When it tries to sync, it will first read the note into memory (in this case it's 150 MB file - which causes the crash), split it and sync piece by piece. Trilium is not really designed to act like big file storage ...

Probably the easiest way to recover from this would be to got to the AAC note, click on "upload new revision" and upload whatever small file. Then go to "note revisions" and click on "delete all revisions". With that the AAC file is completely gone from the database and the sync will continue.