Scott Pakin

I've seen this error message in other contexts. According to some notes I jotted down the last time, two causes I've observed are 1. A mismatch between the compiler used...

I haven't seen that exact error before. Two things to try that come to mind are 1. Generate a static Byfl run-time library instead of a shared library and use...

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...

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...

Here's a simpler diagnostic that might be informative: Change the error message in [`lib/byfl/byfl.cpp`, line 75](https://github.com/lanl/Byfl/blob/63d7598fa668414d4dd7cb1f3f8e64b35bdfb434/lib/byfl/byfl.cpp#L75) also to output `keyID`. If `keyID` is something fishy like 0 or FFF…F, that...

1. In fact, both names appear to contain spaces. Thanks for pointing that out. Are you compiling with `-bf-call-stack`? Spaces are used to separate call-stack entries. 2. Keys are generated...

> I'm also happy to debug with you if there are other things you'd like me to try. It'll probably produce an overwhelming amount of output, but I suppose you...

@markdewing: Wow, that's really strange. I can't imagine how two call stacks would see the same `bf_func_and_parents_id^depth^keyID` but different `17 * bf_func_and_parents_id^depth^keyID` values. Multiplying by a constant shouldn't do anything...

Still, multiplying by a constant shouldn't do anything to resolve a key collision. I'm baffled how this could work.

If you're using an M1 MacBook, the correct architecture should be `macOS-arm64`, but from the error messages you're receiving, it sounds like you have some libraries built incorrectly for `macOS-x86_64`....