Parenthesis causes Segmentation error

[evanhorn]

I was attempting to modify an existing fvSchemes file; when I entered an open parenthesis (e.g., grad(), neovim crashed, and I got “Segmentation fault (core dumped)”. Disabling highlighting eliminates this error, and I noticed that if a space precedes the parenthesis, i.e., grad (, the error does not occur.

Note that this is almost identical to an earlier issue that I posted here.

[FoamScience]

Hi, thanks for reporting this. It's strange that I don't encounter these problems even though I use the parser daily! Will look into it ASAP

[evanhorn]

Well, the other issue I posted only arose because I was using pyFoam template expansion. This one seems to be a bit more problematic, but there may be something specific about my setup that causes this issue. I did not include any diagnostics, e.g., :checkhealth, in the original post (I should have), so I am including it below. If you need any more information, please let me know.

NVIM v0.7.0-dev
Build type: RelWithDebInfo
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -g -O2 -fdebug-prefix-map=/build/neovim-oR9fFZ/neovim-0.7.0~ubuntu1+git202201130047-39a35dd00-dd05b3569=. -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNVIM_TS_HAS_SET_MATCH_LIMIT -DNVIM_TS_HAS_SET_ALLOCATOR -O2 -g -Og -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -DMIN_LOG_LEVEL=3 -I/build/neovim-oR9fFZ/neovim-0.7.0~ubuntu1+git202201130047-39a35dd00-dd05b3569/build/config -I/build/neovim-oR9fFZ/neovim-0.7.0~ubuntu1+git202201130047-39a35dd00-dd05b3569/src -I/build/neovim-oR9fFZ/neovim-0.7.0~ubuntu1+git202201130047-39a35dd00-dd05b3569/.deps/usr/include -I/usr/include -I/build/neovim-oR9fFZ/neovim-0.7.0~ubuntu1+git202201130047-39a35dd00-dd05b3569/build/src/nvim/auto -I/build/neovim-oR9fFZ/neovim-0.7.0~ubuntu1+git202201130047-39a35dd00-dd05b3569/build/include
Compiled by buildd@lcy02-amd64-004

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

Run :checkhealth for more info

Minimal init.vim:

call plug#begin(stdpath('data').'/plugged')

Plug 'nvim-treesitter/nvim-treesitter', {'do': ':TSUpdate'}

call plug#end()

lua << EOF
require("nvim-treesitter.configs").setup {
  ensure_installed = "foam", -- one of "all", "maintained" (parsers with maintainers), or a list of languages
  highlight = {
    enable = true,
  },
}
EOF

:checkhealth (note I removed all non-pertinent lsp and treesitter):

nvim: health#nvim#check
========================================================================
## Configuration
  - OK: no issues found

## Performance
  - OK: Build type: RelWithDebInfo

## Remote Plugins
  - OK: Up to date

## terminal
  - INFO: key_backspace (kbs) terminfo entry: key_backspace=\177
  - INFO: key_dc (kdch1) terminfo entry: key_dc=\E[3~
  - INFO: $COLORTERM='truecolor'

nvim-treesitter: require("nvim-treesitter.health").check()
========================================================================
## Installation
  - WARNING: `tree-sitter` executable not found (parser generator, only needed for :TSInstallFromGrammar, not required for :TSInstall)
  - OK: `node` found v17.0.1 (only needed for :TSInstallFromGrammar)
  - OK: `git` executable found.
  - OK: `cc` executable found. Selected from { vim.NIL, "cc", "gcc", "clang", "cl", "zig" }
    Version: cc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
  - OK: Neovim was compiled with tree-sitter runtime ABI version 14 (required >=13). Parsers must be compatible with runtime ABI.

## Parser/Features H L F I J
  - c              ✓ ✓ ✓ ✓ ✓ 
  - foam           ✓ ✓ ✓ ✓ ✓ 

  Legend: H[ighlight], L[ocals], F[olds], I[ndents], In[j]ections
         +) multiple parsers found, only one will be used
         x) errors found in the query, try to run :TSUpdate {lang}

provider: health#provider#check
========================================================================
## Clipboard (optional)
  - OK: Clipboard tool found: xclip

## Python 3 provider (optional)
  - INFO: pyenv: Path: /home/evanhorn/.pyenv/libexec/pyenv
  - INFO: pyenv: Root: /home/evanhorn/.pyenv
  - WARNING: No Python executable found that can `import neovim`. Using the first available executable for diagnostics.
  - WARNING: Could not load Python 3:
    /home/evanhorn/.pyenv/shims/python3 does not have the "neovim" module.
    /home/evanhorn/.pyenv/shims/python3.10 does not have the "neovim" module.
    /home/evanhorn/.pyenv/shims/python3.9 does not exist: pyenv: python3.9: command not found

    The `python3.9' command exists in these Python versions:
    3.9.9

    Note: See 'pyenv help global' for tips on allowing both
    python2 and python3 to be found.

    /usr/bin/python3.8 does not have the "neovim" module.
    python3.7 not found in search path or not executable.
    /home/evanhorn/.pyenv/shims/python does not have the "neovim" module.
    - ADVICE:
      - See :help |provider-python| for more information.
      - You may disable this provider (and warning) by adding `let g:loaded_python3_provider = 0` to your init.vim
  - INFO: Executable: Not found

## Python virtualenv
  - OK: no $VIRTUAL_ENV

## Ruby provider (optional)
  - INFO: Ruby: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-linux]
  - INFO: Host: /usr/share/rvm/gems/ruby-3.0.0/bin/neovim-ruby-host
  - OK: Latest "neovim" gem is installed: 0.9.0

## Node.js provider (optional)
  - INFO: Node.js: v17.0.1
  - INFO: Nvim node.js host: /home/evanhorn/.nvm/versions/node/v17.0.1/lib/node_modules/neovim/bin/cli.js
  - OK: Latest "neovim" npm/yarn package is installed: 4.10.1

## Perl provider (optional)
  - WARNING: "Neovim::Ext" cpan module is not installed
    - ADVICE:
      - See :help |provider-perl| for more information.
      - You may disable this provider (and warning) by adding `let g:loaded_node_provider = 0` to your init.vim

vim.lsp: require("vim.lsp.health").check()
========================================================================
  - INFO: LSP log level : WARN
  - INFO: Log path: /home/evanhorn/.cache/nvim/lsp.log
  - INFO: Log size: 74845 KB

vim.treesitter: require("vim.treesitter.health").check()
========================================================================
  - INFO: Runtime ABI version : 14
  - OK: Loaded parser for foam: ABI version 13
  - OK: Loaded parser for c: ABI version 13

Note that the Python3 warning is only occurring due to the minimal init.vim; my usual system does not have these warnings.

[evanhorn]

I came across another segmentation fault — I was creating a transportProperties file. I had "nu nu [ 0 2 -1 0 0 0 0 ] 0" and got another segmentation fault as soon as I typed the zero after the square bracket as long as highlighting was enabled.

In my testing, I put "nu nu [ 0 2 -1 0 0 0 0 ] 0.01" (missing the semicolon) in a file; with that, attempting to open the file caused an immediate segmentation fault before the file even opened. Note that this again was only when highlighting was enabled, and if the semicolon was present at the end of the line, the file opened without issue with highlighting.

This seemed related to me, but if you would like me to open another issue, please let me know.

[FoamScience]

I don't seem to be able to reproduce these segfaults. Make sure :LspInstall foam_ls gives you the latest version. Also do you have any plugins which do some sort of parenthesis auto-completion (rainbow ... etc)?

[evanhorn]

I have used :LspInstall foam_ls, and just tried it again to make sure. To ensure that there are no conflicting vim plugins that interfere, I am using the minimal init.vim mentioned in the original post. I have further started bash -norc just to make sure there are no conflicts in my .bashrc. I am still getting the same problem. I also made a point of removing all other lsp's (except for C), in case of an unforseen conflict.

I made a video showing the issue I am having.

Is there any sort of logging or debugging that I could do, to help understand what might be causing this?

[FoamScience]

Hi, so I finally had some free time to poke around this issue. But I don't seem to be able to reproduce your error on a standard schemes file. Nvim version: NVIM v0.7.0-dev+1400-g233014f92 With nvim -u /tmp/config.vim system/fvSchemes (highlighting enabled), where the config file is the minimal one from your earlier issue, no segfaulting occurs. Could you post a sample of your fvSchemes file

Note: you probably need to check what /usr/bin/cc resolves to on your system (if you compiled nvim on your own); We need this to be a recent gcc compiler (eg. gcc-11) otherwise try running with the appimage binary from neovim releases.

[evanhorn]

I believe that I discovered the problem — I was using neovim from the PPA “unstable” branch (v0.7.0-dev). I uninstalled that version and installed the instance from the “stable” branch (v0.6.1), and the issue seems to be resolved.

Thanks for your support on this, and I am sorry for the inconvenience.

[FoamScience]

Oh, if the dev release is buggy then we might have an issue after it gets released then; thanks for reporting anyway

[evanhorn]

I spoke too soon — the “stable” PPA installs v0.6.1, but Treesitter requires 0.7.0. So while it didn't cause issues, Treesitter wasn't working either (hence why I was using the unstable version).

I installed the .deb package (v0.7.0) directly from the neovim GitHub and had the same issue. I also tried the appimage with the same results. Regardless, the nvim-treesitter GitHub page states to use the nightly neovim package, so based on that my assumption is that it should work better with the unstable version.

I am reopening this issue, and have attaching a gzipped tar file of the example directory I am using to test this issue.

[gokberkgunes]

I confirm that similar issues are appearing in my installation. I can reproduce @evanhorn's issues. Also, when writing opening curly brackets, {, after some text in snappyHexMeshDict a segmentation fault occurs. Writing closing curly bracket, }, first avoids the crash.

[FoamScience]

Hi @evanhorn and @gokberkgunes It's been a while, but if you're still using this piece of software, could you please verify that you are no longer experiencing those issues with release v0.3.0?

PR #7 attempts to rewrite some parts of the parse to address these issues

[FoamScience]

For me at least; none of the issues mentioned here are happening, but I don't recall if I was able to reproduce them with my setup honestly

[evanhorn]

My issues appear to be resolved. I have not checked the behavior with snappyHexMesh yet, but I will let you know if I come across anything. I'll give @gokberkgunes an opportunity to test that and/or respond before I close the issue.