Re: unison gui crash with backtrace

Tõivo Leedjärv <[email protected]>
Newsgroups gmane.network.unison.general
Message-ID <CAALvpZQzcQ6Ztum+F0-o_ajCz4hoZpyX4HumwyjO=9k85TMBZg@mail.gmail.com>
On Tue, 27 Feb 2024 at 09:35, Norbert Preining <[email protected]> wrote:
>
> On Tue, 27 Feb 2024, Tõivo Leedjärv wrote:
> > Thank you, this was useful. Seeing the full traces, I now think this
> > may be unrelated to the referenced issue. Or could it be that you have
> > an extremely limited stack size?
>
> I haven't changed anything in the default setup of Arch, I get
>
>         stack size                  (kbytes, -s) 8192
>
> from ulimit.

That is more than enough. It looks like we are not dealing with a
stack overflow here but the issues may still be related. It's too
early to tell.

> > Could you try a binary built with OCaml 4.x? If you can't build easily
> > then you just download from
> > https://urldefense.com/v3/__https://github.com/bcpierce00/unison/releases__;!!IBzWLUs!RRQhIvM9kqx1hWj0rij3JteRihYfBym90DW2aaBSRAuaHZjFCpAmXbMjS2Tij6f6BiDdHjg-KooYAySc9gZu7A$  -- those are all built
> > with 4.x.
>
> I will try, but I need to get back into a situation where I can

caml_try_realloc_stack was introduced in OCaml 5.x and does not exist
in 4.x, that's why it is important to verify the issue with these
builds. Additionally, OCaml 5.x is still considered experimental (it
is expected to become "stable" within a couple of next releases), so
it's important to use a stable compiler to verify the issue.

It is also important to test with lablgtk built with different
compiler versions, as currently it seems that the issue only exists in
the GUI build.

I have tried with lablgtk and the GUI binary both built with OCaml
5.1.0, yet was unable to reporduce the issue.

> reproduce this. After your suggestion I tried the text mode unison and
> that worked on the sync, so I guess I need to wait for some changes
> to accumulate and see if I can reproduce it.

Try to create a reproducible test case. If you can, create a temp
space with a relatively large number of random files, to simulate a
large number of updates to sync. You may start with a very simple test
case, populating a dir with, let's say, 100 000 empty files and see if
syncing those empty files causes the crash. If not, then try
increasing the number of files and/or add some random content to each
file. If the updates that caused the crash included something you'd
think can be relevant (such as an update >4 GB) then you may try
replicating that, too.

-- 
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.