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

Incremental parsing fails with segmentation fault #735

Closed
dbukki opened this issue Apr 26, 2024 · 3 comments · Fixed by #736
Closed

Incremental parsing fails with segmentation fault #735

dbukki opened this issue Apr 26, 2024 · 3 comments · Fixed by #736
Assignees
Labels
Kind: Bug ⚠️ Level: Beginner (1) Plugin: C++ Issues related to the parsing and presentation of C++ projects. Plugin: Metrics Issues related to the code metrics plugin.

Comments

@dbukki
Copy link
Collaborator

dbukki commented Apr 26, 2024

As the name suggests, parsing anything in incremental mode (without a full re-parse) crashes CodeCompass with a segmentation fault.
The issue was first signaled in #714 (comment) but was found to be present in the current master (8e84d84) as well.

@dbukki dbukki added Kind: Bug ⚠️ Plugin: C++ Issues related to the parsing and presentation of C++ projects. labels Apr 26, 2024
@dbukki
Copy link
Collaborator Author

dbukki commented Apr 26, 2024

I have identified two major issues that contribute to the failure of incremental parsing:

[1] The segmentation fault comes from CppMetricsParser::CppMetricsParser during plugin creation:

_astNodeIdCache.insert({anm.astNodeId, node->location.file->id});

node->location.file has not been not loaded with .load(). A read attempt is made on the ID of a non-loaded File object.

Conclusion: This query should be refactored into a view that uses JOINs to achieve the same result without the need for a query_one for each AST node and .load() for each file.

[2] Once that's fixed, a second problem arises in SourceManager::removeFile during the global cleanup phase:

if (relFiles.size() == 1)

.size() is being called on the results of an ODB query that has not been cached prior to this via .cache().
(See https://www.codesynthesis.com/products/odb/doc/manual.xhtml#4.4 )

Even worse yet, even if we did call .cache(), .size() would still always throw odb::result_not_cached when we use SQLite for parsing. I actually ran into this limitation very recently in https://github.com/Ericsson/CodeCompass/pull/734/files#diff-24d453f78f735d12a81ddf3aa0350be52c74b9d362c63a3c3532e5ca6ad4e6dfR148 .
(See https://www.codesynthesis.com/products/odb/doc/manual.xhtml#18.5.1 )

Conclusion: We should eliminate all .size() and .cache() calls on ODB query results from CodeCompass. For as long as we support SQLite, it's a potential source of exceptions.

@mcserep
Copy link
Collaborator

mcserep commented Apr 28, 2024

I have verified that the bug is present on the master branch, but do not occur with the --skip cxxmetricsparser flag. Also, the release/gershwin branch is not affected by the bug, which is prior to the the introduction of the C++ metrics plugin.

@mcserep mcserep added the Plugin: Metrics Issues related to the code metrics plugin. label Apr 28, 2024
@mcserep
Copy link
Collaborator

mcserep commented Apr 28, 2024

I have identified two major issues that contribute to the failure of incremental parsing:

[1] The segmentation fault comes from CppMetricsParser::CppMetricsParser during plugin creation:

_astNodeIdCache.insert({anm.astNodeId, node->location.file->id});

node->location.file has not been not loaded with .load(). A read attempt is made on the ID of a non-loaded File object.

Conclusion: This query should be refactored into a view that uses JOINs to achieve the same result without the need for a query_one for each AST node and .load() for each file.

@dbukki Nice catch 👏

[2] Once that's fixed, a second problem arises in SourceManager::removeFile during the global cleanup phase:

if (relFiles.size() == 1)

.size() is being called on the results of an ODB query that has not been cached prior to this via .cache(). (See https://www.codesynthesis.com/products/odb/doc/manual.xhtml#4.4 )

Even worse yet, even if we did call .cache(), .size() would still always throw odb::result_not_cached when we use SQLite for parsing. I actually ran into this limitation very recently in https://github.com/Ericsson/CodeCompass/pull/734/files#diff-24d453f78f735d12a81ddf3aa0350be52c74b9d362c63a3c3532e5ca6ad4e6dfR148 . (See https://www.codesynthesis.com/products/odb/doc/manual.xhtml#18.5.1 )

Conclusion: We should eliminate all .size() and .cache() calls on ODB query results from CodeCompass. For as long as we support SQLite, it's a potential source of exceptions.

@dbukki We should not optimize for SQLite support, as that is only for development purposes. It was also considered multiple times during the project's lifetime to completly drop SQLite support. If incremental parsing is conflicting with SQLite, then we can make incremental parsing not supporting it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Kind: Bug ⚠️ Level: Beginner (1) Plugin: C++ Issues related to the parsing and presentation of C++ projects. Plugin: Metrics Issues related to the code metrics plugin.
Projects
Status: Done
Status: Done
Development

Successfully merging a pull request may close this issue.

2 participants