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].