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

Better error messages with demangled names + location #404

Open
sloede opened this issue Jan 22, 2024 · 1 comment
Open

Better error messages with demangled names + location #404

sloede opened this issue Jan 22, 2024 · 1 comment

Comments

@sloede
Copy link
Contributor

sloede commented Jan 22, 2024

Sometimes I start batch-wrapping a bunch of library functions to get a C++ wrapper more feature complete, but I overlook that some types have been used that have not been wrapped themselves yet. At the moment, one only gets a (to me) rather cryptic error message such as

C++ exception while wrapping module OpenFHE: No appropriate factory for type St3mapIjSt10shared_ptrIN8lbcrypto11EvalKeyImplINS1_12DCRTPolyImplIN9bigintdyn9mubintvecINS4_5ubintImEEEEEEEEESt4lessIjESaISt4pairIKjSB_EEE
ERROR: LoadError: No appropriate factory for type St3mapIjSt10shared_ptrIN8lbcrypto11EvalKeyImplINS1_12DCRTPolyImplIN9bigintdyn9mubintvecINS4_5ubintImEEEEEEEEESt4lessIjESaISt4pairIKjSB_EEE
Stacktrace:
 [1] register_julia_module
   @ CxxWrap.CxxWrapCore ~/.julia/packages/CxxWrap/5IZvn/src/CxxWrap.jl:393 [inlined]
 [2] readmodule(so_path_cb::OpenFHE.var"#1#2", funcname::Symbol, m::Module, flags::Nothing)
   @ CxxWrap.CxxWrapCore ~/.julia/packages/CxxWrap/5IZvn/src/CxxWrap.jl:751
 [3] wrapmodule(so_path_cb::Function, funcname::Symbol, m::Module, flags::Nothing)
   @ CxxWrap.CxxWrapCore ~/.julia/packages/CxxWrap/5IZvn/src/CxxWrap.jl:761
 [4] top-level scope
   @ /mnt/ssd/home/mschlott/hackathon/fhe/OpenFHE.jl/src/OpenFHE.jl:11
 [5] include
   @ Base ./Base.jl:495 [inlined]
 [6] include_package_for_output(pkg::Base.PkgId, input::String, depot_path::Vector{String}, dl_load_path::Vector{String}, load_path::Vector{String}, concrete_deps::Vector{Pair{Base.PkgId, UInt128}}, source::Nothing)
   @ Base ./loading.jl:2216
 [7] top-level scope
   @ stdin:3

While I am usually able to decipher which type is the offending one (in this case, St3mapIjSt10shared_ptrIN8lbcrypto11EvalKeyImplINS1_12DCRTPolyImplIN9bigintdyn9mubintvecINS4_5ubintImEEEEEEEEESt4lessIjESaISt4pairIKjSB_EEE probably refers to something starting with std::map<std::shared_ptr<lbcrypto..., it's usually rather cumbersume.

Thus, it would be great if there were a demangle function (or if such names were demangled automatically). Furthermore, it would be great - if possible - if the offending location in the wrapper library could be shown as well.

The latter probably requires passing the source location in C++ as something like <filename>:<lineno> with each call to add_type, method etc. Since this is C++, it would probably require an explicit argument (maybe using an appropriate LOC__ preproc macro) that would have to be explicitly given as an argument, but it would certainly make debugging much easier.

@giordano
Copy link

giordano commented Nov 13, 2024

For what is worth, you can use c++filt:

% c++filt --no-strip-underscore _ZSt3mapIjSt10shared_ptrIN8lbcrypto11EvalKeyImplINS1_12DCRTPolyImplIN9bigintdyn9mubintvecINS4_5ubintImEEEEEEEEESt4lessIjESaISt4pairIKjSB_EEE
std::map<unsigned int, std::shared_ptr<lbcrypto::EvalKeyImpl<lbcrypto::DCRTPolyImpl<bigintdyn::mubintvec<bigintdyn::ubint<unsigned long>>>>>, std::less<unsigned int>, std::allocator<std::pair<unsigned int const, std::shared_ptr<lbcrypto::EvalKeyImpl<lbcrypto::DCRTPolyImpl<bigintdyn::mubintvec<bigintdyn::ubint<unsigned long>>>>>>>>

But I don't quite understand why the symbol you mentioned started with St instead of _Z...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants