-
Notifications
You must be signed in to change notification settings - Fork 15
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
Error: duplicate keys found #29
Comments
Is the error repeatable across builds/runs? Specifically, does it name the same function each time? The error comes from a Byfl function that assigns a unique ID to each (possibly non-unique) function name. IDs are chosen such that collisions should be extremely unlikely. I'm thinking it's more likely that the ID-to-function name map is getting corrupted than that an ID conflict is genuinely occurring. Alas, I don't have any good ideas how to test that hypothesis. Maybe run the code through Valgrind and see if it balks at any of it? |
Runs within the same build produce identical results (modulo cosmetic differences in application output). I'll kick off a new build and see if that makes any difference. |
And a completely fresh clone and build produces the same result. So yeah, it looks deterministic. |
Okay, thanks for testing that. Is Valgrind happy with the code, or does it balk at something before Byfl blows up? That'll help distinguish between Byfl's ID-to-function table having been corrupted and a legitimate but unanticipated naming situation (e.g., multiple functions in the same file with the exact same name). |
I'll try to check this, but it looks like I may need a debug build of Python in order to make it play nice with Valgrind. The application is scripted in Python at the code I'm compiling with Byfl is being loaded in as a shared library. |
Here's a simpler diagnostic that might be informative: Change the error message in |
Ok, here's the output:
A couple things:
|
|
That's a good point, all my builds so far have been with For my purposes, This is speculation, but I wonder if somehow having Python on the stack above the C++ calls is causing issues of some sort. Python might be doing strange things like using it's own stack; I'm not 100% sure about this. |
It'll probably produce an overwhelming amount of output, but I suppose you can modify |
I ran into this issue with on a code compiled with
If this is changed to something like |
@markdewing: Wow, that's really strange. I can't imagine how two call stacks would see the same |
Oops - I missed the parenthesis in what I wrote - should be |
Still, multiplying by a constant shouldn't do anything to resolve a key collision. I'm baffled how this could work. |
I'm getting the following error with a large application I'm running. I'd be happy to send repro instructions privately, but so far I'm just not even sure where to even look for problems. Has anyone ever seen anything like this?
(...and it continues for several pages...)
I thought the problem might be related to my use of shared libraries, and I suspected that there might be duplicate symbols included in multiple shared libraries all being loaded into the same execution. But I've tried that scenario in a smaller reproducer, and it works fine. So at the moment I don't have any ideas for what could be causing this.
For background, the application is running in Python, and Python has not been compiled with Byfl. Python loads one or more shared libraries---of which, if I'm doing things right, one and only one has been compiled with Byfl---and then runs some functions in those shared libraries. I've tested a similar scenario in my reproducer (main compiled with the system compiler, libraries compiled with Byfl) and haven't been able to get it to show any problems.
I'm on Ubuntu 16.04 with LLVM 6.0 (with the appropriate Byfl branch). I can provide repro instructions privately if desired.
Thanks.
The text was updated successfully, but these errors were encountered: