clang-uml/docs/troubleshooting.md

Troubleshooting

• General issues
  • clang-uml crashes when generating a diagram
  • Diagram generation is very slow
  • Diagram generated with PlantUML is cropped
  • Clang produces several warnings during diagram generation
  • Errors with C++20 modules and LLVM 18
  • Cannot generate diagrams from header-only projects
  • YAML anchors and aliases are not fully supported
  • Schema validation error is thrown, but the configuration file is correct
  • "fatal error: 'stddef.h' file not found"
  • "error: unknown pragma ignored"
  • "bus error" on Apple Silicon macos
• Class diagrams
  • How can I generate class diagram of my entire project
  • Cannot generate classes for 'std' namespace
• Sequence diagrams
  • Generated diagram is empty
  • Generated diagram contains several empty control blocks or calls which should not be there

General issues

clang-uml crashes when generating a diagram

If clang-uml crashes with a segmentation fault, it is possible to trace the exact stack trace of the fault using the following steps:

First, build clang-uml from source in debug mode, i.e.:

make debug

Then run clang-uml, preferably with -vvv for verbose log output. If your .clang-uml configuration file contains more than 1 diagram, specify only the diagram causing the crash, to make it easier to trace the root cause of the crash, e.g.:

debug/src/clang-uml -vvv -n my_diagram

After clang-uml crashes again, detailed backtrace (generated using backward-cpp library) should be visible on the console.

If possible, create an issue and paste the stack trace and few last logs from the console.

Diagram generation is very slow

clang-uml uses Clang's RecursiveASTVisitor, to traverse the source code. By default, this visitor is invoked on every translation unit (i.e. each entry in your compile_commands.json), including all of their header dependencies recursively. This means, that for large code bases with hundreds or thousands of translation units, traversing all of them will be slow (think clang-tidy slow...).

Fortunately, in most practical cases it is not necessary to traverse the entire source code for each diagram, as all the information necessary to generate a single diagram usually can be found in just a few translation units, or even a single one.

This is where the glob configuration parameter comes in. It can be used to limit the number of translation units to visit for a given diagram, for instance:

diagrams:
  ClassAContextDiagram:
    type: class
    # ...
    glob:
      - src/classA.cpp
    # ...
  InterfaceHierarchyDiagram:
    type: class
    # ...
    glob:
      - src/interfaces/*.cpp
    # ...

This should improve the generation times for individual diagrams significantly.

Furthermore, diagrams are generated in parallel if possible, by default using as many threads as virtual CPU's are available on the system, however it can be adjusted also manually using -t command line option.

Diagram generated with PlantUML is cropped

When generating diagrams with PlantUML without specifying an output file format, the default is PNG. Unfortunately PlantUML will not check if the diagram will fit in the default PNG size, and often the diagram will be incomplete in the picture. A better option is to specify SVG as output format and then convert to PNG, e.g.:

plantuml -tsvg mydiagram.puml
convert +antialias mydiagram.svg mydiagram.png

Clang produces several warnings during diagram generation

During the generation of the diagram clang may report a lot of warnings, which do not occur during the compilation with other compiler (e.g. GCC). This can be fixed easily by using the add_compile_flags config option. For instance, assuming that the warnings are as follows:

... warning: implicit conversion from 'int' to 'float' changes value from 2147483647 to 2147483648 [-Wimplicit-const-int-float-conversion]
... warning: declaration shadows a variable in namespace 'YAML' [-Wshadow]

simply add the following to your .clang-uml configuration file:

add_compile_flags:
  - -Wno-implicit-const-int-float-conversion
  - -Wno-shadow

Alternatively, the same can be passed through the clang-uml command line, e.g.

clang-uml --add-compile-flag -Wno-implicit-const-int-float-conversion \
          --add-compile-flag -Wno-shadow ...

Please note that if your compile_commands.json already contains - for instance -Wshadow - then you also have to remove it, i.e.:

add_compile_flags:
  - -Wno-implicit-const-int-float-conversion
  - -Wno-shadow
remove_compile_flags:
  - -Wshadow

If you don't care about warnings in general during the diagram generation, a more convenient option is to ignore all warnings:

add_compile_flags:
  - -Wno-unknown-warning-option

Errors with C++20 modules and LLVM 18

When running clang-uml on code using C++20 modules, the LLVM version used to build the project must be compatible with the LLVM version linked to clang-uml, otherwise you'll get error like this:

fatal error: malformed or corrupted AST file: 'malformed block record in AST file'

or like this:

error: PCH file uses an older PCH format that is no longer supported

In particular versions 17 and 18 of LLVM are not compatible in this regard.

Cannot generate diagrams from header-only projects

Currently, in order to generate UML diagrams using clang-uml it is necessary that at least one translation unit (e.g. one cpp) exists and it is included in the generated compile_commands.json database.

However, even if your project is a header only library, first check if the generated compile_commands.json contains any entries - if yes you should be fine - just make sure the glob pattern in the configuration file matches any of them. This is due to the fact that most header only projects still have test cases, which are compiled and executed, and which include the headers. These are perfectly fine to be used as translation units to generate the diagrams.

In case, the code really does not contain any translation units, you will have to create one, typically a basic main.cpp which includes the relevant headers should be fine. Also, it's possible to simply create a separate project, with a single translation unit, which includes the relevant headers and create diagrams from there.

In the future there might be a workaround for this in clang-uml.

YAML anchors and aliases are not fully supported

clang-uml uses yaml-cpp library, which currently does not support merging YAML anchor dictionaries, e.g. in the following configuration file the main_sequence_diagram will work, but the foo_sequence_diagram will fail with parse error:

compilation_database_dir: debug
output_directory: output

.sequence_diagram_anchor: &sequence_diagram_anchor
  type: sequence
  glob: [ ]
  start_from:
    - function: 'main(int,const char**)'

diagrams:
  main_sequence_diagram: *sequence_diagram_anchor # This will work
  foo_sequence_diagram:
    <<: *sequence_diagram_anchor # This will not work
    glob: [ src/foo.cc ]
    start_from:
      - function: 'foo(int,float)'

One option around this is to use some YAML preprocessor, such as yq on such file and passing the configuration file to clang-uml using stdin, e.g.:

yq 'explode(.)' .clang-uml | clang-uml --config -

Schema validation error is thrown, but the configuration file is correct

Current version of clang-uml performs automatic configuration file schema validation, and exits if the configuration file is invalid.

In case there is a bug in the schema validation, the schema validation step can be skipped by providing --no-validate command line option.

"fatal error: 'stddef.h' file not found"

This error means that Clang cannot find some standard headers in include paths specified in the compile_commands.json. This typically happens on macOS and sometimes on Linux, when the code was compiled with different Clang version than clang-uml itself.

One solution to this issue is to add the following line to your CMakeLists.txt file:

set(CMAKE_CXX_STANDARD_INCLUDE_DIRECTORIES ${CMAKE_CXX_IMPLICIT_INCLUDE_DIRECTORIES})

Another option is to provide an option (on command line or in configuration file) called query_driver (inspired by the clangd language server - although much less flexible), which will invoke the provider compiler command and query it for its default system paths, which then will be added to each compile command in the database. This is especially useful on macOS as well as for embedded toolchains, example usage:

clang-uml --query-driver arm-none-eabi-g++

Another option is to make sure that the Clang is installed on the system (even if not used for building your project), e.g.:

apt install clang

If this doesn't help to include paths can be customized using config options:

• add_compile_flags - which adds a list of compile flags such as include paths to each entry of the compilation database
• remove_compile_flags - which removes existing compile flags from each entry of the compilation database, it can be provided as a regular string that must match the entire flag or as an object with r: key, which can contain a regular expression that will match a set of flags

For instance:

add_compile_flags:
  - -I/opt/my_toolchain/include
remove_compile_flags:
  - -I/usr/include
  - r: "-m.*"

These options can be also passed on the command line, for instance:

clang-uml --add-compile-flag -I/opt/my_toolchain/include \
          --remove-compile-flag -I/usr/include ...

Also see here.

"error: unknown pragma ignored"

If your code bases uses some non-standard pragmas declarations or you are using older LLVM version, which does not yet support a specific pragma, the warning can be ignore by adding the following compilation flag in the .clang-uml config:

add_compile_flags:
  - -Wno-unknown-pragmas

"bus error" on Apple Silicon macos

On Apple Silicon macos, clang-uml must be linked with LLVM libunwind libraries for proper exception handling, otherwise whenever an exception is thrown somewhere within clang-uml the application is terminated with bus error.

In order to mitigate this error when building clang-uml from sources, the following CMake option should be enabled during build:

-DCMAKE_EXE_LINKER_FLAGS="-L/opt/homebrew/opt/llvm/lib/c++ -Wl,-rpath,/opt/homebrew/opt/llvm/lib/c++"

Class diagrams

How can I generate class diagram of my entire project

I want to generate a diagram containing all classes and relationships in my project - I don't care how big it is going to be.

Of course this is possible, the best way to do this is to specify that clang-uml should only include elements defined in files contained in project sources, e.g.:

diagrams:
  all_classes:
    type: class
    include:
      paths: [ include, src ]

As the diagram will be huge for even medium-sized projects, it will likely not be readable. However, this option can be useful for cases when we want to get a complete JSON model of the codebase using the JSON generator:

clang-uml -g json -n all_classes --progress

Cannot generate classes for 'std' namespace

Currently, system headers are skipped automatically by clang-uml, due to too many errors they produce when generating diagrams, especially when trying to process GCC's or MSVC's system headers by Clang - not yet sure why that is the case.

Basically it's best to either include only specific namespaces through the inclusion filters, e.g.:

include:
  namespaces:
    - myns1::myns12

or explicitly exclude std namespace:

exclude:
  namespaces:
    - std

Hopefully this will be eventually resolved.

Sequence diagrams

Generated diagram is empty

In order to generate sequence diagram the location constraints (from, to or from_to) in configuration file must point to valid locations in the code for the diagram (e.g. function), which must match exactly the function or method signature in the clang-uml diagram model. Look for error in the console output such as:

Failed to find participant mynamespace::foo(int) for start_from condition

which means that either you have a typo in the function signature in the configuration file, or that the function was not defined in the translation units you specified in the glob patterns for this diagram.

Except for simplest methods and functions, it is unlikely to write by hand the exact string representation of the function signature as seen by clang-uml.

To find the exact function signature run clang-uml as follows:

clang-uml -n my_sequence_diagram --print-from | grep foo

Command line flag --print-from will print on stdout all functions and methods available in the diagram model which can be used as starting points for a sequence diagram (similarly --print-to can be used to list all valid functions to be used as call chain end constraints).

Generated diagram contains several empty control blocks or calls which should not be there

Currently, the filtering of call expressions and purging empty control blocks ( e.g. loops or conditional statements), within which no interesting calls were included in the diagram is not perfect. In case the regular namespaces filter is not enough, it is useful to add also a paths filter, which will only include participants and call expressions from files in a subdirectory of your project, e.g.:

   include:
     namespaces:
       - myproject
     paths:
       - src