FS#43241 - [unison] 2.40.102-2 fails with Uncaught exception Failure("input_value: bad bigarray kind")

Attached to Project: Arch Linux
Opened by Carlo Cabanilla (clofresh) - Friday, 26 December 2014, 15:26 GMT
Last edited by Gaetan Bisson (vesath) - Monday, 23 February 2015, 21:51 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Tobias Powalowski (tpowa)
Gaetan Bisson (vesath)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description: I'm syncing my arch desktop with an arm NAS server I have over ssh. The first unison sync works fine, but the second one always fails with Uncaught exception Failure("input_value: bad bigarray kind").

I'm triggering the sync like this:

unison -batch ssh://nashost//path/to/data /home/me/path/to/data

The unison versions at both ends are the same:

$ unison -version
unison version 2.40.102
$ ssh nashost unison -version
unison version 2.40.102

As a sanity check, I've verified that syncing between 2 local directories works ok.

I compiled the version of unison on the NAS host myself using ocaml 4.02.1 to avoid a similar bug I was getting when syncing from OSX to my NAS (https://trac.macports.org/ticket/45621). The bug occurs when one host's unison is compiled with ocaml < 4.02 and another with ocaml 4.02 because ocaml changed their serialization format in 4.02.

I can't tell what version of ocaml unison from the arch repo was compiled with, and when I try to compile it myself, I immediately get a segfault when running unison.

I'm new to arch so I'm not sure if I compiled it correctly, but I tried checking out the packages repo, makepkg -s on the packages/unison branch to let it get the ocaml dependency as well as compiling ocaml by hand first, then compiling unison, and I still get segfaults.
This task depends upon

Closed by  Gaetan Bisson (vesath)
Monday, 23 February 2015, 21:51 GMT
Reason for closing:  Upstream
Additional comments about closing:  See  FS#43925 
Comment by Scott W. Dunlop (swdunlop) - Tuesday, 30 December 2014, 21:07 GMT
This is caused by a change in how OCAML represents format values; if you mix a Unison 2.40.102 built with OCAML version 4.02.1 with one built with a version before 4.02.1, you will occasionally see this exception. In the case of your mac, if you're using macports or homebrew, you're probably using one built with 4.02.1 -- I had the exact same problem today. See upstream http://caml.inria.fr/mantis/view.php?id=6621 for more context.

The upstream unison tarball has been patched without incrementing the version, which also has invalidated the hash in the ABS PKGBUILD. If you apply the attached fix to make these changes, and rebuild with ocaml 4.02.1 or later (which is already in the "extra" repo), the resulting unison will be compatible again -- but you will have broken compatibility of THAT node with every other unison built with an earlier ocaml.

This sort of thing gets right up my nose about Unison. Minor version changes in unison or ocaml breaking compatibility is a serious irritation in a cross platform synchronization tool. :)
Comment by Scott W. Dunlop (swdunlop) - Tuesday, 30 December 2014, 21:09 GMT Comment by Carlo Cabanilla (clofresh) - Tuesday, 30 December 2014, 21:58 GMT
Yay, the command line version works now, thanks. I get a build error for the gtk version though:

File "packages/trunk/src/unison-2.40.102/uigtk2.ml", line 81, characters 26-48:
Error: Unbound module Pango
Makefile.OCaml:414: recipe for target 'uigtk2.cmx' failed
make: *** [uigtk2.cmx] Error 2
==> ERROR: A failure occurred in build().
Aborting...

$ pacman -Q lib32-pango pango
lib32-pango 1.36.8-1
pango 1.36.8-1

Not sure if it's because I have multilib enabled, but I didn't run into that compile error before. I'm ok with just the text version though but not sure if you wanna close this bug and open a new one for the gtk version.

Loading...