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.

Sign up for GitHub

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

Jump to bottom

Handle compilation failures #2

Open
4 tasks
Notgnoshi opened this issue Apr 18, 2022 · 1 comment
Open
4 tasks

Handle compilation failures #2

Notgnoshi opened this issue Apr 18, 2022 · 1 comment

Comments

@Notgnoshi
Copy link
Owner

Notgnoshi commented Apr 18, 2022 •
edited
Loading

These can happen for a number of reasons:

  • Your compilation database might include a source file that's been deleted
  • Your compilation database might be missing certain #defines
  • #pragma once could be treated as an error
  • Add a --compile-fail flag that exits the includegraph.py script on compilation failure.
  • Should nodes for failed TUs be styled?
  • If the first error is in a header, should the whole path from the header to the TU be styled?
  • If preprocessing fails, are any linemarkers parsed?
@opello
Copy link

opello commented Apr 18, 2022

Another example of a failure that we ran into was when the generated command included arguments not supported by the compiler (-m32 was one). It seems like supporting filtering out arbitrary arguments is a good feature from the command line?

Might be addressed by #9 depending on the implementation.

Notgnoshi added a commit that referenced this issue Apr 19, 2022
@Notgnoshi
Reproduce crash when including system headers
690cc9c 
The following
    $ ./includegraph.py examples/example1/build/ -l DEBUG
    2022-04-15 11:42:46,871 - ./includegraph.py - DEBUG - Successfully loaded compilation database from build directory 'examples/example1/build/'
    2022-04-15 11:42:46,872 - ./includegraph.py - DEBUG - Getting headers for /home/nots/Documents/includegraph/examples/example1/src/example1.cpp
    /../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/istream
        /../lib/gcc/x86_64-linux-gnu/9/../../../../include/c++/9/bits/istream.tcc

Crashes in clang.cindex.File.name, which calls clang_getFileName() from
the cdll loaded libclang.so

    #0  0x00007f21db0106ba in clang_getFileName () from /home/nots/Documents/includegraph/.venv/lib/python3.8/site-packages/clang/native/libclang.so
    #1  0x00007f21de1ecff5 in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
    #2  0x00007f21de1ec40a in ?? () from /lib/x86_64-linux-gnu/libffi.so.7
    #3  0x00007f21dd752306 in _ctypes_callproc () from /usr/lib/python3.8/lib-dynload/_ctypes.cpython-38-x86_64-linux-gnu.so

It _doesn't_ crash if you comment out the File.name accesses, but if you
do this, then it breaks the graph generation.
@Notgnoshi Notgnoshi mentioned this issue Apr 19, 2022
Closed
3 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@opello @Notgnoshi