Crash with 'out of memory' on the very start

Support
1

now that official ARM build v1.8 is finally launching on my Asus RT-AC868U, I can’t still make it work as the executable is immediately crashing with out of memory runtime panic.

The dirs are newly created and config is default.

The weird thing is that at the moment of start I don’t see any memory utilization with htop. Plus, I have ~120M free which seems rather enough for newly installed instance, according to https://data.syncthing.net/

After some googling, I tried to set weakHashThresholdPct to 101, though not fully understanding what does that mean :crazy_face:

And, I can’t even profile it during startup:

[monitor] 05:36:26 WARNING: 4 restarts in 6.323566329s; not retrying further

I’m guessing it tries to allocate some physical memory, but what is the amount and how to configure it?

In case if this means something:

[start] 05:36:25 INFO: syncthing v1.8.0 “Fermium Flea” (go1.14.7 linux-arm) teamcity@build.syncthing.net 2020-08-07 06:09:12 UTC … Panic at 2020-08-28T05:36:25Z fatal error: runtime: out of memory

runtime stack: runtime.throw(0xa41f69, 0x16) /usr/local/go/src/runtime/panic.go:1116 +0x5c runtime.sysMap(0x3000000, 0x1000000, 0x13cdb78) /usr/local/go/src/runtime/mem_linux.go:169 +0xa8 runtime.(*linearAlloc).alloc(0x13bbf98, 0x1000000, 0x400000, 0x13cdb78, 0x0) /usr/local/go/src/runtime/malloc.go:1401 +0x94 runtime.(*mheap).sysAlloc(0x13bbc68, 0x1000000, 0x77888, 0x1847edc) /usr/local/go/src/runtime/malloc.go:621 +0x54 runtime.(*mheap).grow(0x13bbc68, 0x800, 0x0) /usr/local/go/src/runtime/mheap.go:1286 +0x134 runtime.(*mheap).allocSpan(0x13bbc68, 0x800, 0x100, 0x13cdb88, 0x1c0f4) /usr/local/go/src/runtime/mheap.go:1124 +0x650 runtime.(*mheap).alloc.func1() /usr/local/go/src/runtime/mheap.go:871 +0x50 runtime.(*mheap).alloc(0x13bbc68, 0x800, 0x101, 0x401f2fff) /usr/local/go/src/runtime/mheap.go:865 +0x58 runtime.largeAlloc(0x1000000, 0x940101, 0x4007cac8) /usr/local/go/src/runtime/malloc.go:1152 +0x6c runtime.mallocgc.func1() /usr/local/go/src/runtime/malloc.go:1047 +0x38 runtime.systemstack(0x183c3c0) /usr/local/go/src/runtime/asm_arm.s:347 +0x84 runtime.mstart() /usr/local/go/src/runtime/proc.go:1041

2

You need more RAM, or possibly swap. The fact that Syncthing can run using less than 120 MiB unfortunately doesn’t mean it will necessarily run on a system that has only that amount free at start.

2 Likes
3

doh… swap… :confounded:

what is the startup memory maximum footprint?

4

I don’t know, sorry. But there’s a lot of virtual memory magic going on, with the runtime “allocating” memory it might not use. If the system rejects that because there is no swap and no overcommit things may fail when they would otherwise work.

It may also be that it will fail anyway or run so slow as to be useless.

1 Like
5

yeah, right…

ok, I’m going to try with the swap (which is going to be slow by itself, running from USB stick). And if that does not worth it, I believe some Pi-board would be the only remaining option…

1 Like
6

heh

swap helped

BUT

after start, it settled with ~10M of RAM and 68k of SWAP :man_facepalming:t2:

anyway, let’s see how it’s gonna chew a 140G+ backup - now that is has a SWAP file on a USB 2.0 stick :laughing:

1 Like
7

2 Likes
8

ohhhh, that’s gonna hurt

LA is 16+ :scream:

and, btw, old Qnap TS-219P surprisingly works with the same ARM build even though its CPU says it is a BogoMIPS type :ok_hand:t2:

9

NAS’s and CPUs… Knowing nothing first hand but reading lots of support requests here, including a quoted message from vendors, makes me think not even the vendors themselves know what they ship, let alone why.

2 Likes
10

well, that wasn’t really good idea…

even with nice tightened to 31 for workers whilst default is 20, it’s nearly freezing so badly and LA raises so high, that everything else, such as OpenVPN bridge is dropping significantly. Though, I would ignore the heat, if DNS relay wasn’t affected — apparently, dnsmasq suffers being queued noticeably far for processing.

As an outcome I can tell that ARM on the router can’t hold any backup sync larger than couple of gigs.

Rsync, on the other hand, works pretty well.

1 Like
11

It is the way.

1 Like
12

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.