Re: Segfault while transfering

Greg Troxel <[email protected]> Thu, 23 May 2024 08:31:32 -0400
Newsgroups gmane.network.unison.general
Message-ID <[email protected]>
Julien David <[email protected]> writes:

> I setup a new replica on quite large directory (~50G) and got a segfault on 
> the first occurence.
>
> Here is the log:
>
> 2024-05-23T11:43:16.592072+00:00 web1-1 kernel: [27651508.074760] 
> unison[187262]: segfault at 7fff04c04fc8 ip 00000000005182c4 sp 
> 00007fff04c04fb0 error 6 in unison[400000+183000] likely on CPU 6 (core 0, 
> socket 0)
> 2024-05-23T11:43:16.621810+00:00 web1-1 kernel: [27651508.100149] Code: 01 
> 00 00 00 48 81 ec 28 08 00 00 64 48 8b 04 25 28 00 00 00 48 89 84 24 18 08 
> 00 00 31 c0 48 81 fe 01 01 00 00 b8 00 01 00 00 <48> 89 4c 24 18 4c 0f 43 
> e8 48 d1 ff 48 d1 ea 48 89 fd 49 89 d7 45

We are very aware of "unison is ungraceful when running out of memory"
but that has generally not manifested as segfaults.

In theory ocaml code should not do this, absent a bug in the ocaml
compiler.  (While I don't think it's very likely, you could also have a
hardware issue.)

But, there is C code in unsion.

My belief, not super well founded, is that unison maintains per-file
data structures, but that the total size of data is not so relevant.  So
the question is perhaps how many files you are syncing, vs total size.
But perhaps something else is going on.

> root@itc-rbx-web1-1:/var/log/unison# unison -version
> unison version 2.53.4 (ocaml 4.14.1)

Actually 2.53.5 is out, since May 6.  I am not claiming it will be
different, but it would be great if you could upgrade and debug with
that.

> Transfer is over ssh with the following options:
>
> times = true
> ignore = Path .ssh
> ignore = Path .unison
> log = true
> logfile = /var/log/unison/source.log
> maxthreads = 10

You didn't mention OS, how much RAM you have, and what your data and
stack sizes are.   I would suggest two paths:

  see if you can find the edges of the bad behavior, by
    - setting times=false
    - setting maxthreads=1
    - watching with ps in a fairly tight loop  to see the mem/rss of the
      process before it crashes
    - turn up data segment size (see ulimit(1)) and stack
    - sync less

  run under gdb and see if you can get a stack trace.  You might have to
  build it yourself and enable some kind of debugging symbols

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].