LLVMSymbolizer: error reading file: No such file or directory

[preejackie]

I have installed cppinsights in my PC. When I run cppinsights it throws some error like this,

LLVMSymbolizer: error reading file: No such file or directory
#0 0x000000000156219a (insights+0x156219a)
#1 0x00000000015605c4 (insights+0x15605c4)
#2 0x0000000001560702 (insights+0x1560702)
#3 0x00007f0326e3f890 __restore_rt (/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
#4 0x000000000054bb7a (insights+0x54bb7a)
#5 0x000000000051b0ca (insights+0x51b0ca)
#6 0x00000000005dccb0 (insights+0x5dccb0)
#7 0x00000000005e1715 (insights+0x5e1715)
#8 0x00000000005a19ae (insights+0x5a19ae)
#9 0x000000000053f484 (insights+0x53f484)
#10 0x000000000053607c (insights+0x53607c)
#11 0x000000000053b1ee (insights+0x53b1ee)
#12 0x000000000053ddb2 (insights+0x53ddb2)
#13 0x000000000051a869 (insights+0x51a869)
#14 0x00007f0326119b97 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21b97)
#15 0x00000000004f53fa (insights+0x4f53fa)
Segmentation fault (core dumped)

What does this error information represent ? How can I get-rid of this ?

Thanks

[andreasfertig]

Hello preejackie,

hard to say. How did you invoke insights? Can you post the file you did try to feed in?

[preejackie]

I invoke insights like this:
insights in.cpp -- -std=c++17.

contents of in.cpp
int main()
{
return 0;
}

[andreasfertig]

Looks like an compilation / installation issue to me. Can you try using the Docker build file which is in the cppinsights source tree: docker_buildenv? Just to ensure that you have a proper environment. The sequence should be:

./build.sh
./compile.sh
./run.sh

Then you have a shell in the docker container. The folder build_docker is mapped in the container. You can store your *.cpp file there.

[preejackie]

Hello, Unfortunately, I didn't have a docker account with me : (, By compilation / installation issue whether you mean by it is the issue of resulting from llvm or cppinsights ?

[andreasfertig]

Well, in general the cpp-content is parsable by cppinsights. What I see here is however, a crash. It now could be, that this comes from a mixed compilation of cppinsights.
You can try to compile it again with debug turned on. That way the symbols may be more readable.

[andreasfertig]

Does it crash also if you just use insights -help?

[preejackie]

As far as I understand from your last comment, this is the issue in cppinsights. If so, Is there any way for getting it correct?
Software Information:
Clang version 8.0.0
G++ 7.3.0
OS - Linux Mint 19
As you mentioned how I can compile it debug turned on ? Is there any special flag for that in insights ?
Thanks

[preejackie]

No it is not crashing when insights -help

[andreasfertig]

I assume that it is due to the way/environment it was compiled. It does not crash on my machine nor in the web version.

Please have at look at the Readme.md for compilation options like DEBUG. If it is turned on, the resulting binary contains all the symbol information. With that your output may contain a clue where and why it crashes.

What does ldd insights report?

[preejackie]

Output of ldd insights:
linux-vdso.so.1 (0x00007ffc903b5000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f2190df2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2190bee000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f21909cf000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2190631000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f21902a3000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f219008b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f218fc9a000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2190ffa000)

[preejackie]

After building with debug=on.
the output of ldd insights is

insights[0x156219a]
insights[0x15605c4]
insights[0x1560702]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x12890)[0x7f786fd3a890]
insights[0x54bb7a]
insights[0x51b0ca]
insights[0x5dccb0]
insights[0x5e1715]
insights[0x5a19ae]
insights[0x53f484]
insights[0x53607c]
insights[0x53b1ee]
insights[0x53ddb2]
insights[0x51a869]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xe7)[0x7f786f014b97]
insights[0x4f53fa]
Segmentation fault (core dumped)

[preejackie]

hi
If you find a solution please let me know

[andreasfertig]

Can you rebuild it with INSIGHTS_STRIP=no that should keep the symbols.

[preejackie]

I have build with insights_strip=no, but it didn't gave any information.
I used : cmake -G"Ninja" ../cppinsights -DCMAKE_BUILD_TYPE=Debug -DINSIGHTS_STRIP=no -DCMAKE_PREFIX_PATH=/home/preejackie/sllvm_install/bin

[andreasfertig]

Hello preejackie,

I'm sorry but without debug symbols I have no clue where to start. I did setup a docker using Mint 19 and everything worked. I cannot reproduce your problem.

Here are the things you might consider:

• Using the Docker image as a start and check, if things work there.
• Use LLVM apt current to get the clang/LLVM binaries and compile against them (see travis or the Dockerfile for examples=.
• Compile clang with debug enabled. This might give the debug symbols.

[andreasfertig]

Hello preejackie,

it could be that I came across your problem and if I'm correct others did as well. See this thread:
https://www.mail-archive.com/[email protected]&q=subject:%22%5C%5Bclazy%5C%5D%2B%5C%5BBug%2B392223%5C%5D%2Bsegmentation%2Bfault%22&o=newest&f=1

And here is one answers which seems to solve it:
https://www.mail-archive.com/[email protected]/msg224146.html

There is also another entry I found from the Clang developers mailinglist:
http://clang-developers.42468.n3.nabble.com/ast-matchers-MatchFinder-default-constructor-segfaults-away-td4061347.html

In short, it seems to help to build it (at least under Linux) with g++ instead of Clang. Did you compile it with Clang?

[andreasfertig]

I'm closing this due to inactivity.