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

Check that loaded dll*.so have matching ABI #6807

Closed
vicuna opened this issue Mar 11, 2015 · 5 comments
Closed

Check that loaded dll*.so have matching ABI #6807

vicuna opened this issue Mar 11, 2015 · 5 comments

Comments

@vicuna
Copy link

vicuna commented Mar 11, 2015

Original bug ID: 6807
Reporter: @whitequark
Status: acknowledged (set by @damiendoligez on 2015-03-18T13:58:02Z)
Resolution: open
Priority: normal
Severity: feature
Category: dynlink and natdynlink
Monitored by: @diml @ygrek @hcarty

Bug description

Every once in a while (quite often actually) I have a variation on this conversation:

[ 1125.114750] camlp4[4634]: segfault at 41 ip 00007f505b8b7bd0 sp 00007fff24a3f610 error 4 in dllbigarray.so[7f505b8b5000+5000]
unsure what to make of this (from dmesg)
[trying to compile a project on debian]
xxx: most likely you are trying to use opam with camlp4 from a different switch
or system camlp4
try doing which camlp4 and echo CAML_LD_LIBRARY_PATH
if one refers to opam and other does not, you have a problem
they do, thanks

This is very confusing to a newcomer who does not understand the intricacies of OCaml's runtime system. Yet it would be very easy to look up a symbol inside a dll and verify that it matches a symbol inside the runtime, thus verifying that the ABI matches.

This mechanism would be imperfect, since you can't easily fingerprint a C library ABI, but even if the fingerprint would be just the compiler version, it would fix the all the failures of this kind I've seen.

@vicuna
Copy link
Author

vicuna commented Feb 24, 2017

Comment author: @damiendoligez

FTR this looks like a good idea.

@github-actions
Copy link

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label May 11, 2020
@whitequark
Copy link
Member

Still an issue.

@stedolan stedolan self-assigned this May 12, 2020
@stedolan stedolan removed the Stale label May 12, 2020
@github-actions
Copy link

github-actions bot commented Jun 2, 2021

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions
Copy link

github-actions bot commented Jul 4, 2022

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

@github-actions github-actions bot added the Stale label Jul 4, 2022
@github-actions github-actions bot closed this as completed Aug 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants