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

Lablgtk-based GUI crashes with OCaml 4.03+beta1 #7162

Closed
vicuna opened this issue Mar 3, 2016 · 7 comments
Closed

Lablgtk-based GUI crashes with OCaml 4.03+beta1 #7162

vicuna opened this issue Mar 3, 2016 · 7 comments
Assignees
Labels
Milestone

Comments

@vicuna
Copy link

vicuna commented Mar 3, 2016

Original bug ID: 7162
Reporter: maro
Assigned to: @garrigue
Status: closed (set by @damiendoligez on 2016-03-24T15:47:36Z)
Resolution: fixed
Priority: normal
Severity: crash
OS: Linux
OS Version: Ubuntu 14.04
Target version: 4.03.0+dev / +beta1
Fixed in version: 4.03.0+dev / +beta1
Category: ~DO NOT USE (was: OCaml general)
Related to: #7161
Monitored by: @diml bobot @yakobowski

Bug description

The Frama-C GUI, based on lablgtk, currently crashes when compiled with OCaml 4.03+beta1: a segmentation fault is produced in the Gtk code.

Here's the end of the backtrace:

Program received signal SIGSEGV, Segmentation fault.
gtk_tree_view_row_inserted (model=0x160ae60, path=0x1561a40, iter=0x15ca020, data=0x12d1270) at /build/gtk+2.0-KsZSEA/gtk+2.0-2.24.23/gtk/gtktreeview.c:8464
8464 /build/gtk+2.0-KsZSEA/gtk+2.0-2.24.23/gtk/gtktreeview.c: No such file or directory.
(gdb) bt
#0 gtk_tree_view_row_inserted (model=0x160ae60, path=0x1561a40, iter=0x15ca020, data=0x12d1270) at /build/gtk+2.0-KsZSEA/gtk+2.0-2.24.23/gtk/gtktreeview.c:8464
#1 0x00007ffff72f33b8 in g_closure_invoke () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#2 0x00007ffff7304d3d in ?? () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#3 0x00007ffff730ca29 in g_signal_emit_valist () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#4 0x00007ffff730cce2 in g_signal_emit () from /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
#5 0x0000000000b15a8a in ml_custom_model_row_inserted (tree_model_val=, path=140737220365248, row=140737220365296) at ml_gtktree.c:1517
#6 0x00000000009fd42f in camlGTree__fun_8134 ()
#7 0x0000000000aad5b5 in camlList__iter_1258 () at list.ml:77
#8 0x0000000000638687 in camlDesign__display_warnings_33195 () at src/plugins/gui/design.ml:1428
....

The last line is part of the Frama-C code.

I believe there might be several different factors contributing to this bug, but so far, after a manual bisection, I ended up at commit 8851e6b (Allow allocating custom blocks with finalizers in the minor heap.). The preceding commit (ceb5e0b) does not crash.

I still don't know if the following is related, but when testing my program using ceb5e0b or 8851e6b, on longer runs, the following messages are produced in the console:

[ocaml] (use Sys.enable_runtime_warnings to control these warnings)
[ocaml] channel opened on file '/tmp/cppannot31a858.c' dies without being closed
[ocaml] channel opened on file '/tmp/cppannot11320f.c' dies without being closed

I had never seen these messages before, and they likely appear with several other commits. The named files are temporary files produced by Frama-C, which indicates that there might also be a bug in our code base. In the end, I think that there is an influence of several previously unnoticed bugs.

Steps to reproduce

  • Compile the OCaml code corresponding to commit 8851e6b;

  • Use it to compile Frama-C dependencies (especially lablgtk);

  • Download, compile and install the latest public release of Frama-C (Magnesium);

  • Create a "test.c" file containing a single line:

    int i = 1.1;

  • Run "frama-c-gui test.c". The program should crash almost instantly with the segmentation fault described above.

Note: it seems that it is not possible to install lablgtk directly from the stable versions of camlp4, so I preprocessed the lablgtk files and removed the camlp4 dependence. With the attached archive (which includes a "opam" file), it should be possible to locally do a opam pin on the lablgtk package and install the remaining Frama-C dependencies from opam.

I'll later try to add the (approximate) sequence of commands necessary to reproduce the entire installation.

File attachments

@vicuna
Copy link
Author

vicuna commented Mar 3, 2016

Comment author: @garrigue

Seeing the name of the commit, this is not too surprising.
Indeed, lablgtk assumes that blocks created by alloc_custom do not move
(and disables compaction to ensure that).
I suppose we'll have to fix lablgtk.
Is there a simple way to ensure that a block allocated by alloc_custom is in the main heap?
I mean, other than using alloc_shr by hand?

@vicuna
Copy link
Author

vicuna commented Mar 3, 2016

Comment author: bobot

For reference the original bug solved by the commit is #3612, the merge request introducing this commit is #92

@vicuna
Copy link
Author

vicuna commented Mar 4, 2016

Comment author: dobenour

I think that this is simply a bug in LablGTK -- in fact, I think that assuming that any block in the OCaml heap does not move is a bug. LablGTK needs to be fixed to use a registered GC root to access all OCaml objects. If this is too expensive, a single root could hold a reference to an array of Obj.t that is resized when needed, and the references could be replaced by integers.

The other solution would be for OCaml to provide an API to allocate blocks in the C heap together with counterparts in the OCaml heap.

@vicuna
Copy link
Author

vicuna commented Mar 4, 2016

Comment author: maro

Is it still useful to prepare a script to reproduce it? If so, I can do it, but it seems less needed now.

@vicuna
Copy link
Author

vicuna commented Mar 4, 2016

Comment author: @damiendoligez

@garrigue you'll have to use alloc_shr.

@vicuna
Copy link
Author

vicuna commented Mar 5, 2016

Comment author: @garrigue

Can you try to apply the alloc_custom.diff patch to lablgtk and/or use the git version (either ocamlforge or github, they are the same)?
I basically reimplemented the original alloc_custom, which always calls alloc_shr.

If somebody had the courage to track down the places where it is required to remove them, this could be a better solution, but it is so easy to break something that works...
Originally this trick was only intended to be used for text iterators, but it may have creeped around.

@vicuna
Copy link
Author

vicuna commented Mar 7, 2016

Comment author: maro

I've updated my 4.03 branch to commit 95410ef and then applied your patch, and it works without problems.

I performed several tests and did not get any crashes or issues related to lablgtk.

I did not test 100% of our GUI, but I do believe every major component has been tested.

Thank you for the investigation and the patch!

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

2 participants