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
natdynlink reproducible segfault #4839
Comments
Comment author: @alainfrisch I reported such a problem some time ago: #4229. In fact, you don't even need to use dynlink in order to break the type system when you link in different modules with the same name/signature; regular packing/linking will do: #4231. |
Comment author: @alainfrisch Turning to later: no clear resolution plan, and bug present for years. |
Comment author: @xavierleroy Just refusing to dynlink a compilation unit A if the main program already contains a unit named A would go a long way towards fixing this group of PRs. |
Comment author: @ivg I've uploaded two solutions, the first one is to bail out if someone tries to reinitialize a unit that is already in the main program. (See fail.patch) Another approach, that is less conservative, and requires some consideration is to silently ignore such units and keep moving. (See ignore.patch). I would advocate for the latter solution. First of all it looks safe, as we check the module that we ignore for a consistency with that one, that is already loaded. Second, it has intuitive behavior, i.e., it is ok to link two programs, that imports the same library. Third ... if we will bail out, then it may break plugin solutions for BAP, Frama-C, and maybe other projects. But honestly speaking, I still can't proof to myself, that this is a safe solution. As far as I understand, the root of the problem here is that whenever we create a plugin that references some library as P.S. I'm not sure what Xavier meant by "refuse". To raise an error or to silently ignore? |
Comment author: @ivg I've upload a |
Comment author: @glondu
This is what should be done in my humble opinion. In Ocsigen, we create a Findlib package per plugin, and use Findlib in the host program to figure out what cmxs need to be loaded at dynlink time. |
Comment author: @ivg
Yep, we're using the same approach. But findlib even with its new dynload module, that records already loaded dependencies and predicates, still can't protect you fully from a corruption of state and segfaults. The problem is that findlib doesn't have an access to an internal |
Comment author: @mshinwell This has been fixed by #1063 - please continue any discussion there. |
Original bug ID: 4839
Reporter: furuse
Assigned to: @mshinwell
Status: resolved (set by @mshinwell on 2017-06-09T15:17:38Z)
Resolution: duplicate
Priority: normal
Severity: crash
Version: 3.11.1
Target version: later
Category: otherlibs
Related to: #4229 #4231 #6462 #6950 #6957
Monitored by: @ivg @rixed @glondu
Bug description
A packed module in a dll cmxs overwrites the packed module of the same name in the host program at dynlinking. If these two packed modules have incompatible signatures, the program may easily seg-faults.
We have found this when we wrongly created dll cmxs linking with a module of the host program. I upload a reproducible example. make all test shows the crash.
File attachments
The text was updated successfully, but these errors were encountered: