SIGSEGV when running opir #11
Comments
|
Hmm, not entirely sure. Running the exact same code on my machine works fine, albeit erroring out on something else.. Which clang package do you have installed? And I assume you have the right glfw backend installed? |
|
I didn't have glfw installed, as its bundled with raylib. I have installed my system's glfw (added the /usr/include/GLFW/ in importc) but no change. I package clang 13.0.0-4 from Manjaro installed (stable branch). |
|
I'm also on Manjaro and when I installed raylib it asked me if I wanted to install the glfw dependency as Wayland or X11. |
|
Till now I was using statically built raylib, I will try again with shared raylib from the Manjaro repo and report back to you. |
|
I get the same error, however a thing I forgot to report is I don't have nimble installed. I compiled opir and modified futhark to run my nim.cfg in futhark directory seems to work fine... |
|
I think the problem lies with libclang-nim, my system has installed libclang.so, but the bindings don't use the dynlib pragma. using passL: "-static -lclang" reveals I don't have a static libclang installed. |
|
Aha, that might explain it, but in that case it's a bit weird that Opir was even able to build. You should be able to just add Opir to your path so you don't have to modify Futhark itself. Shouldn't make a difference though. Which libclang version do you use? I have my own fork where I've fixed some bugs in the official version. |
The one provided by manjaro, which is probably a rebuilt of https://archlinux.org/packages/extra/x86_64/clang/ |
|
|
|
I added |
|
Here is the Opir output when I run your code on my machine: http://ix.io/3Lcf |
|
By the way, these are my packages: |
This is much better than what I was working with thus far, thank you for making futhrak and opir! |
|
Just too bad that Opir crashes on your machine. These kinds of errors are also super hard for me to debug since I can't reproduce the error.. |
|
Futhark was working nice with my project, then I accepted to install ubuntu upgrades on my 20.04 LTS and suddenly I face same The change should be outside futhark and libclang-nim Thanks to a stable setup before the upgrade, I recompiled opir in debug mode traced down the problem to the line: nimble install futhark@#head project: cmdline: futhark-includes.h: nim output: Line 343 in 875a7f5 (gdb) run -I/usr/lib/clang/10/include -I/usr/include/gdal /home/jack/.cache/nim/nimmap_d/futhark-includes.h seems to happen inside clang_getTranslationUnitCursor dump repr unit (of stat /usr/lib/x86_64-linux-gnu/libclang-10.so.1 File: /usr/lib/x86_64-linux-gnu/libclang-10.so.1
Size: 34221680 Blocks: 66840 IO Block: 4096 regular file
Device: 815h/2069d Inode: 8392614 Links: 2
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2022-01-12 06:09:06.795501871 +0100
Modify: 2020-04-20 07:12:09.000000000 +0200
Change: 2021-12-06 03:28:40.168317608 +0100nm -D /usr/lib/x86_64-linux-gnu/libclang-10.so.1 | grep clang_getTranslationUnitCursor debugging ...
import sugar
dump repr index
dump fname
for i in 0..args:
dump commandLine[i]
dump args
var unit = parseTranslationUnit(index, fname.cstring,
commandLine, args.cint, nil, 0, CXTranslationUnit_DetailedPreprocessingRecord.cuint or CXTranslationUnit_SkipFunctionBodies.cuint)
dump unit.getNumDiagnostics
..cat /tmp/imports-20501.h not quite sure what's going on, seems that the output of |
|
Yeah, I also got that far when I was debugging this. That's why I was trying to find if we had any differences in packages or setup. Not really sure what to do about this.. It might be that the Clang wrapper is incorrect? |
|
just tried compiling and linking opir against libclang-12 instead of libclang-10, but I got same results I was actually trying to figure out what happened 2 hours ago when I installed ubuntu upgrades via gnome apt, but with my surprise there's no info of that operation in /var/log/apt |
|
In my case, the same problem happens on both libclang-10, 11 and 12, so I'd stick with 10 as I've always use it for the past months on different futhark based projects. I've installed the debug symbols, so I've a line to blame: I've grabbed the original file source version CXCursor clang_getTranslationUnitCursor(CXTranslationUnit TU) {
if (isNotUsableTU(TU)) {
LOG_BAD_TU(TU);
return clang_getNullCursor();
}
ASTUnit *CXXUnit = cxtu::getASTUnit(TU);
return MakeCXCursor(CXXUnit->getASTContext().getTranslationUnitDecl(), TU); // 4208
}edit: found same ref line on github https://github.com/llvm/llvm-project/blob/ef32c611aa214dea855364efd7ba451ec5ec3f74/clang/tools/libclang/CIndex.cpp#L4208 considering the fact that gdb bt shows that SIGSEGV happens in clang_getTranslationUnitCursor, it means that |
|
diving into the issue edit in index.nim (cland-#head pkg) to reflect original struct type
# CXTranslationUnit* = pointer # CXTranslationUnitImpl
CXTranslationUnit* = ptr object # CXTranslationUnitImpl
cIdx*: CXIndex
theASTUnit*: pointer
cXStringPool*: pointer
diagnostic*: pointer
overridenCursorsPool*: pointer
commentToXML*: pointer
parsingOptions*: cuint
arguments: pointerchecks in opir.nim var unit = parseTranslationUnit(index, fname.cstring,
commandLine, args.cint, nil, 0, CXTranslationUnit_DetailedPreprocessingRecord.cuint or CXTranslationUnit_SkipFunctionBodies.cuint)
deallocCStringArray(commandLine)
assert not unit.isNil
# assert first and last struct fields
assert unit.cIdx == index
assert unit.parsingOptions == (CXTranslationUnit_DetailedPreprocessingRecord.cuint or CXTranslationUnit_SkipFunctionBodies.cuint)
#
assert not unit.theASTUnit.isNil
echo repr unit.theASTUnitoutput at least we know that |
|
created minimal example to reproduce the error: import clang
static:
# any content will fail, including empty file
writeFile("futhark-includes.h", """
#include "gdal.h"
""")
var
commandLineParams = @[
"-I/usr/lib/clang/10/include",
"-I/usr/include/gdal"]
fname = "futhark-includes.h"
index = createIndex(0, 0)
commandLine = allocCStringArray(commandLineParams)
var unit = parseTranslationUnit(index, fname.cstring,
commandLine, commandLineParams.len.cint, nil, 0, CXTranslationUnit_DetailedPreprocessingRecord.cuint or CXTranslationUnit_SkipFunctionBodies.cuint)
deallocCStringArray(commandLine)
block: # testing stuff
assert not unit.isNil
assert unit.getNumDiagnostics == 0
# assert first and last struct fields
assert unit.cIdx == index
assert unit.parsingOptions == (CXTranslationUnit_DetailedPreprocessingRecord.cuint or CXTranslationUnit_SkipFunctionBodies.cuint)
assert not unit.theASTUnit.isNil
echo repr unit.theASTUnit
echo unit.getTranslationUnitSpelling
echo repr unit.getCXTUResourceUsage
discard getTranslationUnitCursor(unit) # SIGSEGV
assert falseoutput |
|
I've created a docker based nimble package to replicate the issue and exclude single-machine case https://github.com/arkanoid87/futhest it includes 2 Dockerfile to replicate error on ubuntu and alpine-linux I've also just included a working plain C example that does not crash #include <assert.h>
#include <stdio.h>
#include "clang-c/Index.h"
enum CXChildVisitResult
visitor(CXCursor cursor, CXCursor parent, CXClientData clientData) {
CXFile file;
unsigned int line;
unsigned int column;
unsigned int offset;
CXSourceLocation loc = clang_getCursorLocation(cursor);
clang_getFileLocation(loc, &file, &line, &column, &offset);
CXString filename = clang_getFileName(file);
printf("%s [%d:%d, %d]\n", clang_getCString(filename), line, column, offset);
clang_disposeString(filename);
return CXChildVisit_Continue;
}
int main (void) {
CXIndex Idx = clang_createIndex(0, 0);
CXTranslationUnit TU = clang_parseTranslationUnit(Idx,
"src/header.h", NULL, 0, NULL, 0, 0);
assert(TU != NULL);
CXCursor cursor = clang_getTranslationUnitCursor(TU);
clang_visitChildren(cursor, visitor, NULL);
clang_disposeTranslationUnit(TU);
printf("END");
} |
|
Relevant forum post: https://forum.nim-lang.org/t/8796 EDIT: solution found, is a regression in nim compiler
remember to clean your ~/.cache/nim/project_* folder after swtiching New issue: nim-lang/Nim#19378 |
|
Aha! My machine was still running Nim 1.6.0 which was why I didn't see the error. Hopefully this will be fixed quickly! |
This comment has been minimized.
This comment has been minimized.
|
Might be, NimLSP (which is what I'm using for Vim) embeds the Nim compiler and calls it directly in the same way that nimsuggest does. |
|
related issue see also |
|
Does nim-lang/Nim#19385 help? |
|
I confirm bug is gone in latest devel success thanks! |
|
Given that I just had the same issue I confirm his confirmation. |
|
deleting the right cache dir for your nim project is |
|
With 1.6.4 released this seems to have been fixed upstream. If this still occurs please re-open the issue. |
I have installed raylib globally as per https://github.com/raysan5/raylib/wiki/Working-on-GNU-Linux#build-raylib-using-make
My nim code is:
The output I am getting when running
opir -I/usr/local/include -I/usr/lib/clang/13.0.0/include ~/.cache/nim/makeray_r/futhark-includes.h:Any way to debug this further?
The text was updated successfully, but these errors were encountered: