Unison crashes on some platforms when built with 4.02

[vicuna]

Original bug ID: 6621
Reporter: bcpierce
Status: closed (set by @xavierleroy on 2016-12-07T10:36:52Z)
Resolution: not a bug
Priority: normal
Severity: crash
Platform: Multiple
OS: Multiple
Version: 4.02.1
Category: ~DO NOT USE (was: OCaml general)
Monitored by: @diml @yallop

Bug description

I've been getting reports that Unison doesn't work when built on some platforms with 4.02 (either 4.02.0 or 4.02.1). Here's what I think I know:

• 4.01 seems to work reliably
• 4.02 seems to work on Mavericks, but not Yosemite
• 4.02 seems not to work on "a almost up-to-date linux system with gcc 4.8.3 and glibc 2.19"

A message about this from a user is in the "additional information"

Steps to reproduce

Grab Unison tarball from

http://www.seas.upenn.edu/~bcpierce/unison//download/releases/stable/unison-2.40.102.tar.gz

Unpack. Go inside.

do

make text
./unison

Additional information

I'm also seeing this broken build of unison 2.40.102. It happened when
I upgraded to OS X 10.10 Yosemite and had to rebuild all MacPorts.
Building with either ocaml 4.02.0 (in macports) or 4.02.1 (outside of
macports) results in a nonfunctional unison.

Outputting the version works, but not running unison as usual:

% ./unison -version
unison version 2.40.102

% ./unison
X?8zsh: segmentation fault (core dumped) ./unison

It outputs 15 bytes of junk for some reason:

% ./unison &> output.txt
zsh: segmentation fault (core dumped) ./unison &> output.txt

% xxd output.txt
0000000: 58fc 1200 0100 0000 3803 1300 0100 00 X.......8......

% lldb ./unison -c /cores/core.9045
(lldb) target create "./unison" --core "/cores/core.9045"
w?????????|???????????????????????????????1
}M��5�9Q|????????????????????????????????????????????????????????)?????????????????????????????????????????????????)?????????|???????????????????????????????1
}M��5�9Q|????????????????????????????????????????????????????????(???????????????????????????)
???????????????????????????|????????????)A???????????(???????????????????????????????????????????????????????????M%�MQ=@(?????????????????????????????????(??????????????????????????(???????????????????????????(????????????????????????(????????????????????????????(????????????(??????????????????????????����������6C�2�V?6???�7F?��&V�6??�?�6?v?�?�4?u5D?��?�g&�?R�3�?��?������������6C�2�V?6??����g&�?R�3�?��?��c?c3sCc�c#&C�?????F"?��V?

[vicuna]

Comment author: @yallop

This is quite likely to be a result of the change in representation of format values, which are no longer represented as strings:

#6017

The Ubase.fprintf function used in Unison accepts a format argument:

https://github.com/pascal-bach/Unison/blob/d00bd534/src/ubase/uprintf.mli#L18

and uses an unsafe coercion to treat the format value as a string:

https://github.com/pascal-bach/Unison/blob/d00bd534/src/ubase/uprintf.ml#L16-L17

Replacing the coercion (Obj.magic) with a call to the string_of_format function may help:

http://caml.inria.fr/pub/docs/manual-ocaml/libref/Pervasives.html#VALstring_of_format

[vicuna]

Comment author: @yallop

However, the fact that Unison works with 4.02 on Mavericks but not on Yosemite suggests that there may be other issues.

[vicuna]

Comment author: @damiendoligez

make text

That doesn't work, you have to "make UISTYLE=text" instead.

[vicuna]

Comment author: @damiendoligez

I've reproduced the bug (complete with 15 bytes of output that look like two pointers followed by a NUL byte) with 4.02.1 on MacOSX 10.7 (Mountain Lion) so it doesn't look like a problem with the new MacOS version.

As for uprintf.ml, you should get rid of this old unsafe code and use Printf.kfprintf instead. The only use I found in is util.ml and you can replace it with:

let msg f =
clear_infos (); Printf.kfprintf (fun c -> flush c; show_infos ()) stderr f

I've tested it on Mountain Lion and it seems to fix the problem.

[vicuna]

Comment author: bcpierce

Yes, this fix seems to work. I've built a new Unison version for people to test.

I also think I was incorrect that it was working on Mavericks, so we don't need to worry about other issues for the time being. For now, this can be marked as fixed.

[vicuna]

Comment author: macosx12345

Additionnally, when compiled with ocaml 4.02 and the X11 interface under Mac OS 10.8, unison (or lablgtk2 ?) crashes non systematically with a segmentation fault in lablgtk2's function ml_g_signal_emit_by_name.

Steps to reproduce: compile unison with Gtk2 support ("UISTYLE=gtk2"), start unison in graphics mode ("unison -ui graphic") and play with the dialog box showing the list of files to update. After a few random clicks, unison should crash. I tried both lablgtk2 2.18.0 and 2.18.2 and ocaml 4.02.0 and 4.02.1 with the same trouble.

Reverting to compiling lablgtk2 2.18.2 and unison with ocaml 4.01 solved (of course) the issue.

[vicuna]

Comment author: @yallop

macosx12345: your bug should be reported to the Unison team.

[vicuna]

Comment author: @garrigue

macosx12345: Thank you for confirming the impact of the bug in lablgtk.
There was a first report in September, but I didn't know how severe it was.
This is already fixed in the git version of lablgtk; I shall make a new release soon.