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
Comments
Comment author: @garrigue Seeing the name of the commit, this is not too surprising. |
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. |
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. |
Comment author: @damiendoligez @garrigue you'll have to use alloc_shr. |
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)? 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... |
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! |
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
The text was updated successfully, but these errors were encountered: