Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unison crashes on some platforms when built with 4.02 #6621

Closed
vicuna opened this issue Oct 20, 2014 · 8 comments
Closed

Unison crashes on some platforms when built with 4.02 #6621

vicuna opened this issue Oct 20, 2014 · 8 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Oct 20, 2014

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
Copy link
Author

vicuna commented Oct 20, 2014

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
Copy link
Author

vicuna commented Oct 20, 2014

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
Copy link
Author

vicuna commented Oct 21, 2014

Comment author: @damiendoligez

make text

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

@vicuna
Copy link
Author

vicuna commented Oct 21, 2014

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
Copy link
Author

vicuna commented Oct 21, 2014

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
Copy link
Author

vicuna commented Oct 28, 2014

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
Copy link
Author

vicuna commented Oct 28, 2014

Comment author: @yallop

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

@vicuna
Copy link
Author

vicuna commented Oct 29, 2014

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.

@vicuna vicuna closed this as completed Dec 7, 2016
@vicuna vicuna added the bug label Mar 20, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant