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

Catastrophic error ("assertion failed: cast_node: cast to class type") when compiling a CodeQL database from Chromium #16782

Closed
flowerhack opened this issue Jun 18, 2024 · 6 comments
Labels
C++ question Further information is requested

Comments

@flowerhack
Copy link

flowerhack commented Jun 18, 2024

Hi hello,

I'm a committer for the Chromium project & we've been experimenting with building CodeQL databases of Chromium.

The Bug

While building the Chromium CodeQL database, we get multiple instances (~thousands) of "catastrophic error" in build-tracer.log, and, when attempting to query the resulting database, we observe that large portions of the code are not reflected in the database query results.

I've pinpointed one of the types of catastrophic error we're seeing, which manifests with the following error message:

In construct_text_message: "../../third_party/dawn/src/dawn/native/webgpu_absl_format.cpp", line 118: internal error: assertion failed: cast_node: cast to class type (exprutil.c, line 9462 in cast_node)

          new absl::ParsedFormat<'u', 's', 's', 's'>("{ binding: %u, visibility: %s, %s: %s }");
                                                    ^

Reproducing The Bug

I have created a standalone file which can be used to reproduce this bug, which is attached here as webcpu_absl_format_true_ii.cc.txt (please remove the .txt extension; this was to make the Github attachment uploader happy).

Reproduction steps (assumes that webcpu_absl_format_true_ii.cc is in /YOUR/ROOT/HERE; assumes Clang 19; assumes Linux):

(1) codeql database init --language=cpp --source-root=/YOUR/ROOT/HERE/SOME-EMPTY-DIRECTORY /YOUR/ROOT/HERE/repro-catastrophic-db --overwrite

(2) codeql database trace-command /YOUR_ROOT_HERE/repro-catastrophic-db --working-dir=/YOUR/ROOT/HERE -- clang -fno-ident -fno-strict-aliasing -fstack-protector -funwind-tables -fPIC -pthread -fcolor-diagnostics -fmerge-all-constants -mllvm -instcombine-lower-dbg-declare=0 -mllvm -split-threshold-for-reg-with-hint=0 -ffp-contract=off -fcomplete-member-pointers -m64 -msse3 -Wno-builtin-macro-redefined -D__DATE__= -D__TIME__= -D__TIMESTAMP__= -ffile-compilation-dir=. -no-canonical-prefixes -ftrivial-auto-var-init=pattern -O0 -fno-omit-frame-pointer -gdwarf-4 -g2 -gdwarf-aranges -gsplit-dwarf -ggnu-pubnames -fvisibility=hidden '-std=c++20' -gsimple-template-names -fno-exceptions -fno-rtti '-nostdinc++' -fvisibility-inlines-hidden -c /usr/local/google/home/flowerhack/webcpu_absl_format_true_ii.cc -o webcpu_absl_format_true_ii.o

(3) codeql database finalize -j=-1 /YOUR/ROOT/HERE/repro-catastrophic-db.

At the conclusion of these steps there should be logs in build-tracer.log and logs/extractor/ indicating the failure.

In addition to (1) webcpu_absl_format_true_ii.cc (the reproducer file), please find attached (2) the build-tracer.log and (3) the relevant extractor logfile (c66e3.log) from running this on my own machine, which will hopefully be useful for debugging/triage.

I do have the logs for the entire Chromium build available upon request, but as you might imagine, those files are very large and may not be as useful to you as this standalone reproducer.

A fix for this bug (or, guidance on how we might be holding it wrong!) would be extremely helpful for us here in Chromium. Please let me know if you need any more information. Thank you!

build-tracer.log
c66e3.log
webcpu_absl_format_true_ii.cc.txt

@mmdriley
Copy link

Here's a smaller repro, which just requires a recent version of Abseil in the include path:

#include "absl/strings/str_format.h"

void f() {
  (void)new absl::ParsedFormat<'u', 's', 's', 's'>("{ binding: %u, visibility: %s, %s: %s }");
}

I tried to make a CodeQL database for this file with:

codeql database init test-cc --source-root=${PWD} --language=cpp
codeql database trace-command -- test-cc clang -std=c++20 -Iabseil-cpp test.cc -c -o test.o
codeql database finalize test-cc

and then looking through the extractor logs I see:

[E 00:05:03 3313830] Warning[extractor-c++]: In construct_text_message: "test.cc", line 4: internal error: assertion failed: cast_node: cast to class type (exprutil.c, line 9610 in cast_node)

    (void)new absl::ParsedFormat<'u', 's', 's', 's'>("{ binding: %u, visibility: %s, %s: %s }");
                                                    ^

@mbg
Copy link
Member

mbg commented Jun 19, 2024

Hi @flowerhack and @mmdriley 👋

Thanks for reporting this and the other issue, as well as including examples for how to reproduce the problems. I have passed both of them on to the relevant engineering team.

@jketema
Copy link
Contributor

jketema commented Jun 19, 2024

Hi @flowerhack ,

Thanks for the report and the reproducer. Having access that the preprocessed file is absolutely great. It makes it much easier to act upon this issue, instead of having to wade through several GBs of logs produced during Chromium builds. For now I've filed an internal issue for this, and hopefully we can get to this fairly soon.

@jketema
Copy link
Contributor

jketema commented Jun 20, 2024

@mmdriley

Thanks for the additional repro. I just like to mention that although the original repro from @flowerhack is larger, it is self contained, which is ultimately more useful, as it means we don't have to install any external dependencies while investigating the issue.

@jketema
Copy link
Contributor

jketema commented Jun 20, 2024

Reported to our frontend provider.

@jketema
Copy link
Contributor

jketema commented Jul 9, 2024

We received a patch for this issue. This should be part of CodeQL 2.18.1, which will be released within a month's time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C++ question Further information is requested
Projects
None yet
Development

No branches or pull requests

4 participants