How did the issue present itself before you enabled UBSAN? (Are you sure its the same issue?)
Is there some way you could make/share a minimal repro case? cheers, sam On Wed, Aug 9, 2023 at 7:13 AM 'Mike Lischke' via emscripten-discuss < emscripten-discuss@googlegroups.com> wrote: > Hi all, > > I have a memory alignment problem in a library, which I want to use via > wasm. To get more information I enabled USAN which reported the error, but > it makes no sense to me, because the error is within the STL, not my code. > The class I use is std::unordered_set<> with a custom hasher and a custom > comparer. The pointer given to the `insert` method (the error happens > already on first insertion) is aligned, I triple checked that. Here's the > full stack trace: > > This is the pointer that should be inserted in the set: > > proposed: 0x3bebe8 > > /opt/homebrew/Cellar/emscripten/3.1.43/libexec/cache/sysroot/include/c++/v1/__memory/unique_ptr.h:469:12: > runtime error: reference binding to misaligned address 0x3307474f for type > 'std::__hash_node_base<std::__hash_node<antlr4::dfa::DFAState *, void *> *> > *', which requires 4 byte alignment > 0x3307474f: note: pointer points here > RuntimeError: memory access out of bounds > at __ubsan::Diag::~Diag() > (wasm://wasm/0a18e74a:wasm-function[23303]:0xa1fae2) > at handleTypeMismatchImpl(__ubsan::TypeMismatchData*, unsigned long, > __ubsan::ReportOptions) (wasm://wasm/0a18e74a:wasm-function[23315]:0xa20b40) > at __ubsan_handle_type_mismatch_v1 > (wasm://wasm/0a18e74a:wasm-function[23314]:0xa20695) > at > std::__2::unique_ptr<std::__2::__hash_node_base<std::__2::__hash_node<antlr4::dfa::DFAState*, > void*>*>* [], > std::__2::__bucket_list_deallocator<std::__2::allocator<std::__2::__hash_node_base<std::__2::__hash_node<antlr4::dfa::DFAState*, > void*>*>*>>>::operator[][abi:v160004](unsigned long) const > (wasm://wasm/0a18e74a:wasm-function[16520]:0x6dde0a) > at > std::__2::pair<std::__2::__hash_iterator<std::__2::__hash_node<antlr4::dfa::DFAState*, > void*>*>, bool> std::__2::__hash_table<antlr4::dfa::DFAState*, > antlr4::dfa::DFA::DFAStateHasher, antlr4::dfa::DFA::DFAStateComparer, > std::__2::allocator<antlr4::dfa::DFAState*>>::__emplace_unique_key_args<antlr4::dfa::DFAState*, > antlr4::dfa::DFAState* const&>(antlr4::dfa::DFAState* const&, > antlr4::dfa::DFAState* const&) > (wasm://wasm/0a18e74a:wasm-function[16515]:0x6dbbfb) > at std::__2::__hash_table<antlr4::dfa::DFAState*, > antlr4::dfa::DFA::DFAStateHasher, antlr4::dfa::DFA::DFAStateComparer, > std::__2::allocator<antlr4::dfa::DFAState*>>::__insert_unique[abi:v160004](antlr4::dfa::DFAState* > const&) (wasm://wasm/0a18e74a:wasm-function[16387]:0x6cb146) > at std::__2::unordered_set<antlr4::dfa::DFAState*, > antlr4::dfa::DFA::DFAStateHasher, antlr4::dfa::DFA::DFAStateComparer, > std::__2::allocator<antlr4::dfa::DFAState*>>::insert[abi:v160004](antlr4::dfa::DFAState* > const&) (wasm://wasm/0a18e74a:wasm-function[16382]:0x6ca8f2) > at > antlr4::atn::LexerATNSimulator::addDFAState(antlr4::atn::ATNConfigSet*, > bool) (wasm://wasm/0a18e74a:wasm-function[16379]:0x6c9deb) > at antlr4::atn::LexerATNSimulator::matchATN(antlr4::CharStream*) > (wasm://wasm/0a18e74a:wasm-function[16306]:0x6a4858) > at antlr4::atn::LexerATNSimulator::match(antlr4::CharStream*, unsigned > long) (wasm://wasm/0a18e74a:wasm-function[16291]:0x6a095c) > > To me it looks like the set tries to insert a random memory address. I > added console logging in the entire path, including the hasher, to see > what's going on (feeling like debugging in the 90s :-( ) and everything > looks good. The hash is created and looks valid, but after that the crash > happens. So what else could I do to debug further? > > For completeness, this is how the set member is defined: > > std::unordered_set<DFAState *, DFAStateHasher, DFAStateComparer> states; > // States are owned by this class. > > No unique pointers involved here, so this must be something internal to > the set. > > Mike > -- > www.soft-gems.net > > -- > You received this message because you are subscribed to the Google Groups > "emscripten-discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to emscripten-discuss+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/ECB3B320-77B3-4B6E-A51C-8199FC547AAB%40googlemail.com > <https://groups.google.com/d/msgid/emscripten-discuss/ECB3B320-77B3-4B6E-A51C-8199FC547AAB%40googlemail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "emscripten-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to emscripten-discuss+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-eEvdH3LBcenC7bLnVWmvsHmmWo2gqnweYzdeARZG%3DZA%40mail.gmail.com.
