To me this looks like a heap smash. Try enabling the address sanitizer. On Thu, Aug 10, 2023 at 10:18 AM 'Sam Clegg' via emscripten-discuss < [email protected]> wrote:
> 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 < > [email protected]> 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 [email protected]. >> 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 [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-eEvdH3LBcenC7bLnVWmvsHmmWo2gqnweYzdeARZG%3DZA%40mail.gmail.com > <https://groups.google.com/d/msgid/emscripten-discuss/CAL_va2-eEvdH3LBcenC7bLnVWmvsHmmWo2gqnweYzdeARZG%3DZA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- - https://cube20.org/ <http://cube20.org/> - https://golly.sf.net/ <http://golly.sf.net/> - https://alpha.twizzle.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/emscripten-discuss/CAGia-%3DXVNr5Hm_WSTbqdqV0De-7KkHLn0AwJtU-J6AOqM%2Be4Kg%40mail.gmail.com.
