gdb hangs when printing certain objects
Reported by
msten...@opera.com,
Oct 14 2016
|
|||||||
Issue descriptionThis has to be a gdb bug or at least unfavorable gdb behavior, but I'm reporting it here for now. This was introduced by https://codereview.chromium.org/2370673002 - found by bisecting. I don't know if gdb has problems with enum classes in general, or what this is about. What's even weirder is that in my example below, EDisplay isn't even part of the data. Printing InlineBox* m_inlineBoxWrapper in LayoutBox is one example (gdb: "p m_inlineBoxWrapper"). Since this is a member of LayoutBox, it also hangs when printing LayoutBox or any derived object. It doesn't hang forever. For about 40 seconds or so on my machine. And it only hangs once per session. Still... pretty annoying. This happens in both gdb 7.7.1 and 7.11.1 (both standard Debian packages). gn args for the builds that I use: is_component_build = true enable_nacl=false cc_wrapper="ccache" gdb_index = true Invoking gdb via gud-gdb in emacs. Command line arguments to content_shell: --single-process
,
Nov 10 2016
That's what I did. Weird, right?
,
Nov 17 2016
Just compiled and installed gdb 7.12. Still a problem.
,
Nov 23 2016
If I set gdb_index to false (which is default) in gn args, the problem goes away. But then I get slow content_shell startup times instead.
,
Nov 23 2016
I found out what's going on: The symbol lookup machinery in gdb doesn't seem to be able to distinguish between the EDisplay::InlineBox enum (which was introduced by the blamed CL) value and the InlineBox class (in Source/core/layout/line/InlineBox.h). So whenever we use gdb anywhere near the InlineBox class, it goes through all the compilation units that have EDisplay defined (that's more than 2500 files). Or something like that. I don't really know much about the inner workings of gdb, but running the "set debug symtab-create 1" command before running into trouble seemed to suggest something to that effect going on. Whether this is a bug in gdb or in clang, I do not know. But we can work around the problem by using some other name than InlineBox in EDisplay. In this particular case, that even makes quite a lot of sense, since InlineBox and Box are non-standard property values for an outdated flexbox spec. Before the spec went CR, the values were renamed to "flex" and "inline-flex", rather than "box" and "inline-box". So I'll just go ahead and rename them. That said, I wouldn't be surprised if there be similar name clashes elsewhere. So ideally this should be fixed. If you know whom to contact in your team who works on things like the clang compiler bundled with the chromium sources, maybe you could Cc them. I'll file a CL shortly.
,
Nov 23 2016
,
Nov 24 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/40d77a4fb4d16dec83ecd5be8c98633ac15b6021 commit 40d77a4fb4d16dec83ecd5be8c98633ac15b6021 Author: mstensho <mstensho@opera.com> Date: Thu Nov 24 14:42:46 2016 EDisplay enum class: Rename [Inline]Box to Webkit[Inline]Box. The "box" and "inline-box" values (or rather: "-webkit-box" and "-webkit-inline-box") for "display" are for an early-stage version of the flexbox spec, which the web embraced before the flexbox spec got around to going CR (which uses the values "flex" and "inline-flex" instead). Furthermore: Having both EDisplay::InlineBox enum value and the InlineBox class (in Source/core/layout/line/InlineBox.h) confuses the symbol lookup in gdb, which causes a ~40 seconds freeze [1] when working on something that involves the InlineBox class. [1] For component builds with gdb_index set to true in gn BUG= 655961 Review-Url: https://codereview.chromium.org/2524903003 Cr-Commit-Position: refs/heads/master@{#434316} [modify] https://crrev.com/40d77a4fb4d16dec83ecd5be8c98633ac15b6021/third_party/WebKit/Source/core/css/CSSPrimitiveValueMappings.h [modify] https://crrev.com/40d77a4fb4d16dec83ecd5be8c98633ac15b6021/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp [modify] https://crrev.com/40d77a4fb4d16dec83ecd5be8c98633ac15b6021/third_party/WebKit/Source/core/layout/LayoutObject.cpp [modify] https://crrev.com/40d77a4fb4d16dec83ecd5be8c98633ac15b6021/third_party/WebKit/Source/core/layout/LayoutObject.h [modify] https://crrev.com/40d77a4fb4d16dec83ecd5be8c98633ac15b6021/third_party/WebKit/Source/core/layout/ng/ng_block_layout_algorithm.cc [modify] https://crrev.com/40d77a4fb4d16dec83ecd5be8c98633ac15b6021/third_party/WebKit/Source/core/style/ComputedStyle.h [modify] https://crrev.com/40d77a4fb4d16dec83ecd5be8c98633ac15b6021/third_party/WebKit/Source/core/style/ComputedStyleConstants.h
,
Nov 24 2016
,
Nov 25 2016
Before we close this, could you please file a bug against GDB for this? :) There is some great context here that they could use to try and fix this bug. We should really investigate switching to LLDB... :)
,
Nov 25 2016
Nvm, I'll do this :) Thanks mstensho!
,
Jan 5 2017
I filed a bug with upstream gdb. [I couldn't find an existing one there.] https://sourceware.org/bugzilla/show_bug.cgi?id=21027 |
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by sashab@chromium.org
, Nov 10 2016