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

Panics demangling some symbols from a Linux build of Firefox #272

Open
gabrielesvelto opened this issue Oct 19, 2022 · 6 comments
Open

Panics demangling some symbols from a Linux build of Firefox #272

gabrielesvelto opened this issue Oct 19, 2022 · 6 comments

Comments

@gabrielesvelto
Copy link

I've used the current master branch of cpp_demangle on the symbols produced by a local Firefox build on my machine and found 9 that cause cpp_demangle to panic. The list of affected symbols is available here. These were generated by clang 14.0.5.

@gabrielesvelto gabrielesvelto changed the title Panics demangling some symbols from a Firefox Linux build Panics demangling some symbols from a Linux build of Firefox Oct 19, 2022
@gabrielesvelto
Copy link
Author

I've fed the symbols into llvm-cxxfilt and the results are here. These all seem to have an odd ::$_<number> component, for example:

std::__invoke_result<mozilla::webgl::ChooseDeviceReplacement(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)::$_41>

@khuey
Copy link
Collaborator

khuey commented Oct 19, 2022

These fail to demangle here (with "error: an error occurred when formatting an argument") but none of them panic. What is the panic stack?

@khuey
Copy link
Collaborator

khuey commented Oct 19, 2022

These seem to trigger a loop when printing the symbol that eventually hits the recursion limit.

@khuey
Copy link
Collaborator

khuey commented Oct 20, 2022

I fixed one issue that's definitely a cpp_demangle bug, but after that we still don't agree with LLVM or libiberty (which also don't agree with each other)

cpp_demangle

mozilla::CompactPair<mozilla::net::SimpleChannelCallbacks*, mozilla::DefaultDelete<mozilla::net::SimpleChannelCallbacks> >::CompactPairHelper<mozilla::net::SimpleChannelCallbacksImpl<nsAnnoProtocolHandler::NewFaviconChannel(nsIURI*, nsIURI, nsILoadInfo*, nsIChannel**)::$_15, already_AddRefed<nsILoadInfo*> NS_NewSimpleChannel<nsAnnoProtocolHandler, nsIChannel**>(nsIURI, nsILoadInfo, nsAnnoProtocolHandler*, nsIChannel**&&)::{lambda(bool, nsIChannel, nsIURI)#1}, nsAnnoProtocolHandler>*, mozilla::DefaultDelete<already_AddRefed<nsILoadInfo*> NS_NewSimpleChannel<nsAnnoProtocolHandler, nsIChannel**>(nsIURI, nsILoadInfo, nsAnnoProtocolHandler*, nsIChannel**&&)::{lambda(bool, nsIChannel, nsIURI)#1}> >(mozilla::DefaultDelete<already_AddRefed<nsILoadInfo*> NS_NewSimpleChannel<nsAnnoProtocolHandler, nsIChannel**>(nsIURI, nsILoadInfo, nsAnnoProtocolHandler*, nsIChannel**&&)::{lambda(bool, nsIChannel, nsIURI)#1}>)

lllvm-cxxfilt 16 (llvm/llvm-project@c0d954a)

mozilla::CompactPair<mozilla::net::SimpleChannelCallbacks*, mozilla::DefaultDelete<mozilla::net::SimpleChannelCallbacks>>::CompactPair<mozilla::net::SimpleChannelCallbacksImpl<nsAnnoProtocolHandler::NewFaviconChannel(nsIURI*, nsIURI, nsILoadInfo*, nsIChannel**)::$_15, already_AddRefed<nsILoadInfo*> NS_NewSimpleChannel<nsAnnoProtocolHandler, nsIChannel**>(nsIURI, nsILoadInfo, nsAnnoProtocolHandler*, nsIChannel**&&)::'lambda'(bool, nsIChannel, nsIURI), nsAnnoProtocolHandler>*, mozilla::DefaultDelete<already_AddRefed<nsILoadInfo*> NS_NewSimpleChannel<nsAnnoProtocolHandler, nsIChannel**>(nsIURI, nsILoadInfo, nsAnnoProtocolHandler*, nsIChannel**&&)::'lambda'(bool, nsIChannel, nsIURI)>>(already_AddRefed<nsILoadInfo*>&&, nsIChannel**)

libiberty (binutils 2.38.50)

mozilla::CompactPair<mozilla::net::SimpleChannelCallbacks*, mozilla::DefaultDelete<mozilla::net::SimpleChannelCallbacks> >::CompactPairHelper<mozilla::net::SimpleChannelCallbacksImpl<nsAnnoProtocolHandler::NewFaviconChannel(nsIURI*, nsAnnoProtocolHandler, nsILoadInfo*, nsIChannel**)::$_15, NS_NewSimpleChannel<mozilla::net::SimpleChannelCallbacksImpl, nsIChannel*>(nsAnnoProtocolHandler, nsIURI*, mozilla::net::SimpleChannelCallbacksImpl*, nsIChannel*&&)::{lambda(bool, nsILoadInfo*, nsAnnoProtocolHandler)#1}, mozilla::net::SimpleChannelCallbacksImpl>*, mozilla::DefaultDelete<nsIChannel*&&> >(already_AddRefed&&, mozilla::net::SimpleChannelCallbacksImpl<nsAnnoProtocolHandler::NewFaviconChannel(nsIURI*, nsAnnoProtocolHandler, nsILoadInfo*, nsIChannel**)::$_15, NS_NewSimpleChannel<mozilla::net::SimpleChannelCallbacksImpl, nsIChannel*>(nsAnnoProtocolHandler, nsIURI*, mozilla::net::SimpleChannelCallbacksImpl*, nsIChannel*&&)::{lambda(bool, nsILoadInfo*, nsAnnoProtocolHandler)#1}, mozilla::net::SimpleChannelCallbacksImpl>**)

It would really help to know where these symbols come from in the Mozilla source to determine which (if any) are correct.

@gabrielesvelto
Copy link
Author

I believe that's coming from here. But it's just a guess given the types that show up in the demangled versions.

@khuey
Copy link
Collaborator

khuey commented Oct 20, 2022

After looking at this with fresh eyes I think the symbol is incorrectly mangled. The above comes from demangling

_ZN7mozilla11CompactPairIPNS_3net22SimpleChannelCallbacksENS_13DefaultDeleteIS2_EEECI2NS_6detail17CompactPairHelperIS3_S5_LNS7_11StorageTypeE1ELS9_0EEEIPNS1_26SimpleChannelCallbacksImplIZN21nsAnnoProtocolHandler17NewFaviconChannelEP6nsIURISD_P11nsILoadInfoPP10nsIChannelE4$_15Z19NS_NewSimpleChannelISC_SJ_E16already_AddRefedISG_ESD_SF_PT_OT0_EUlbSH_SD_E_SC_EENS4_ISS_EEEEOSN_SQ_

CompactPairHelper doesn't appear in the llvm-cxxfilt demangling despite appearing in the symbol. And detail doesn't appear in the demangling in any tool! I think itanium-cxx-abi/cxx-abi#68 is also present here.

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