You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original bug ID: 6957 Reporter:@ivg Assigned to:@mshinwell Status: resolved (set by @mshinwell on 2017-06-09T16:09:47Z) Resolution: duplicate Priority: normal Severity: minor Version: 4.02.2 Target version: later Category: otherlibs Related to:#4229#4231#4839#6462#6950 Monitored by:@ivg
Bug description
Disclaimer
It is hard to reduce this issue to a small test case, mostly because, it looks like that many different parts of infrastructure are involved. So, to reproduce, one need to install bap from opam.
Short description
A dynamically linked module accidentally accesses the same named module from the host program, thus provoking a segfault.
The setup
In BAP library we use dynamic loading to dynamically load program analysis plugins into our main application. Plugins are loaded with Dynlink.load_file and created with our own ocamlbuild plugin, that basically is doing the following: (1) build a cmxa of all files that constitute a plugin, (2) build a shared object from it with ocamlfind ocamlopt -linkpkg -shared xxx.cmxa -o xxx.plugin.
The problem
In main application we have a filename options.ml. In a plugin I also have the same named module, that define a record type and value of that type. Fields of the record are defined as mutable. If I make the fields immutable everything works fine. If I rename the file, there is also no segfaults.
But if everything is left as it is, then when I load and execute the loaded code, the first field of the record is not a None (as it was initialized), but points to Some value, that provokes a segmentation fault, when I try to dereference it.
Wild guess
It looks suspicious that the issue only manifests itself, when field records are marked as mutable. Maybe there is some optimization pass, that is responsible for that.
yes, looks like another manifestation. We saw that previously, when we link plugin with the a library, that is already linked into a host program. We even created a workaround - our ocamlbuild plugin prevents from this, by excluding this libraries. (I wasn't sure that this was a bug).
Original bug ID: 6957
Reporter: @ivg
Assigned to: @mshinwell
Status: resolved (set by @mshinwell on 2017-06-09T16:09:47Z)
Resolution: duplicate
Priority: normal
Severity: minor
Version: 4.02.2
Target version: later
Category: otherlibs
Related to: #4229 #4231 #4839 #6462 #6950
Monitored by: @ivg
Bug description
Disclaimer
It is hard to reduce this issue to a small test case, mostly because, it looks like that many different parts of infrastructure are involved. So, to reproduce, one need to install bap from opam.
Short description
A dynamically linked module accidentally accesses the same named module from the host program, thus provoking a segfault.
The setup
In BAP library we use dynamic loading to dynamically load program analysis plugins into our main application. Plugins are loaded with
Dynlink.load_file
and created with our own ocamlbuild plugin, that basically is doing the following: (1) build a cmxa of all files that constitute a plugin, (2) build a shared object from it withocamlfind ocamlopt -linkpkg -shared xxx.cmxa -o xxx.plugin
.The problem
In main application we have a filename
options.ml
. In a plugin I also have the same named module, that define a record type and value of that type. Fields of the record are defined as mutable. If I make the fields immutable everything works fine. If I rename the file, there is also no segfaults.But if everything is left as it is, then when I load and execute the loaded code, the first field of the record is not a
None
(as it was initialized), but points toSome
value, that provokes a segmentation fault, when I try to dereference it.Wild guess
It looks suspicious that the issue only manifests itself, when field records are marked as mutable. Maybe there is some optimization pass, that is responsible for that.
Steps to reproduce
$ opam install bap
$ tar xzvf segfault
$ bapbuild use.plugin
$ bap -luse /bin/true
File attachments
The text was updated successfully, but these errors were encountered: