dstep dumps core on a simple header

[tbrowder]

Given a file t.h, with contents:

extern const char *const sys_errlist[];

Run dstep on it and get a core dump:

$ dstep -x c -o t.d t.c
Segmentation fault (core dumped)

I built dtep from this repo on a Debian Linux 64-bit system (after building and installing the dmd suite from its repos).

[jacob-carlborg]

Hmm, I can not reproduce this, at least not on OS X. Which version of DMD and libclang are you using? Could you please try the precompiled version of DStep as well.

[tbrowder]

dmd: DMD64 D Compiler v2.065
libclang: clang version 3.5 (trunk 195954)

When I tried the pre-compiled binary I get:

./dstep: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./dstep)

[tbrowder]

I have tried to debug dstep but can't get any info from "gdb dstep core".

The "file" command shows embedded symbols and I compiled dstep with:

$ dub -d -f build

[jacob-carlborg]

Ok, I'll see what I can do.

[mihails-strasuns]

I can confirm it on Arch Linux x64

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00000000005ae3cc in rt.deh_win64_posix.terminate() ()
(gdb) bt
#0  0x00000000005ae3cc in rt.deh_win64_posix.terminate() ()
#1  0x000000000059b515 in _d_throwc ()
#2  0x00000000005ad804 in onAssertErrorMsg ()
#3  0x00000000005975d5 in _d_assert_msg ()
#4  0x0000000000518845 in _D5dstep10translator4Type13translateTypeFE5clang1c5index10CXTypeKindbZAya (rewriteIdToObject=true, kind=<incomplete type>) at dstep/translator/Type.d:302
#5  0x0000000000517bc0 in _D5dstep10translator4Type13translateTypeFS5clang4Type4TypebbZAya (applyConst=true, rewriteIdToObject=true, type=...) at dstep/translator/Type.d:62
#6  0x000000000057fc75 in _D5dstep10translator10Translator10Translator8variableMFS5clang6Cursor6CursorC5dstep10translator6Output6StringZAya (this=0x7f8affb99a00, context=0x7f8affb9cb40, cursor=...) at dstep/translator/Type.d:19
#7  0x000000000057f8eb in _D5dstep10translator10Translator10Translator9translateMFS5clang6Cursor6CursorS5clang6Cursor6CursorZAya (this=0x7f8affb99a00, parent=..., cursor=...) at dstep/translator/Translator.d:124
#8  0x000000000057f420 in _D5dstep10translator10Translator10Translator9translateMFZv14__foreachbody1MFKS5clang6Cursor6CursorKS5clang6Cursor6CursorZi (this=0x7fff21ea14d8, __applyArg1=<error reading variable>, 
    __applyArg0=<error reading variable>) at dstep/translator/Translator.d:68
#9  0x000000000051ea6f in _D5clang7Visitor18DeclarationVisitor7opApplyMFDFKS5clang6Cursor6CursorKS5clang6Cursor6CursorZiZi14__foreachbody2MFKS5clang6Cursor6CursorKS5clang6Cursor6CursorZi (this=0x7fff21ea1430, 
    __applyArg1=<error reading variable>, __applyArg0=<error reading variable>) at clang/Visitor.d:93
#10 0x000000000051e886 in _D5clang7Visitor7Visitor15visitorFunctionUS5clang1c5index8CXCursorS5clang1c5index8CXCursorPvZE5clang1c5index18CXChildVisitResult (cursor=..., parent=..., data=0x7fff21ea13b8) at clang/Visitor.d:47
#11 0x00007f8afedaf044 in ?? () from /usr/lib/libclang.so
#12 0x00007f8afedb2059 in ?? () from /usr/lib/libclang.so
#13 0x00007f8afedaee24 in ?? () from /usr/lib/libclang.so
#14 0x00007f8afedb6754 in clang_visitChildren () from /usr/lib/libclang.so
#15 0x000000000051e82e in _D5clang7Visitor7Visitor7opApplyMFDFKS5clang6Cursor6CursorKS5clang6Cursor6CursorZiZi (this=0x7fff21ea1490, dg=...) at clang/Visitor.d:32
#16 0x000000000051e9f7 in _D5clang7Visitor18DeclarationVisitor7opApplyMFDFKS5clang6Cursor6CursorKS5clang6Cursor6CursorZiZi (this=0x7fff21ea1490, dg=...) at clang/Visitor.d:91
#17 0x000000000057f2a2 in _D5dstep10translator10Translator10Translator9translateMFZv (this=0x7f8affb99a00) at dstep/translator/Translator.d:62
#18 0x000000000054ff44 in _D5dstep6driver11Application11Application15startConversionMFAyaZv (this=0x7f8affb99d00, file=...) at dstep/driver/Application.d:102
#19 0x000000000054fa4a in _D5dstep6driver11Application11Application3runMFZv (this=0x7f8affb99d00) at dstep/driver/Application.d:50
#20 0x000000000054e517 in _D6dstack11application11Application11Application10debugStartMFZi (this=0x7f8affb99d00) at dstack/dstack/application/Application.d:128
#21 0x000000000054e485 in _D6dstack11application11Application11Application6_startMFZi (this=0x7f8affb99d00) at dstack/dstack/application/Application.d:100
#22 0x000000000054e601 in _D6dstack11application11Application11Application51__T5startTC5dstep6driver11Application11ApplicationZ5startFAAyaZi (args=...) at dstack/dstack/application/Application.d:35
#23 0x0000000000512677 in _Dmain (args=...) at dstep/driver/DStep.d:15
#24 0x000000000059b7ec in rt.dmain2._d_run_main() ()
#25 0x000000000059b746 in rt.dmain2._d_run_main() ()
#26 0x000000000059b7ac in rt.dmain2._d_run_main() ()
#27 0x000000000059b746 in rt.dmain2._d_run_main() ()
#28 0x000000000059b6c7 in _d_run_main ()
#29 0x0000000000512b35 in main ()

(updated with debug symbols)

[mihails-strasuns]

Failed assertion comes from translateType():

    default: assert(0, "Unhandled type kind " ~ kind.toString);

[mihails-strasuns]

libclang 3.4.1 , dstep built from tag 0.1.0

[jacob-carlborg]

I've been able to reproduce this on a different computer, probably due to a newer versions of libclang. Seems like they added a couple of new types in later versions. I'll see if I can fix this during the weekend. In the meantime, it will probably work in you downgrade to an older version of libclang.

I usually use 3.1. I probably should upgrade, but I haven't done so so far because I don't need any of the newer features and libclang is supposed to be ABI compatible with later versions.

[jacob-carlborg]

Ok, I see. In libclang 3.1 the type is defined as CXType_Unexposed. Seems they opened up some more types in later versions.

[mihails-strasuns]

I usually use 3.1. I probably should upgrade, but I haven't done so so far because I don't need any of the newer features and libclang is supposed to be ABI compatible with later versions

3.1 is rather old, it makes impossible to use dstep with system package of clang, I guess will need to hotfix it for Arch.

btw, there should probably be enforcement here instead of assertion, so that release version still have reasonable error message instead of segfault.

[jacob-carlborg]

btw, there should probably be enforcement here instead of assertion, so that release version still have reasonable error message instead of segfault.

How about returning "<unimplemented>", as is already done by other types that are not handled, and in debug mode have an assertion?

[mihails-strasuns]

Up to you, I am just pointing that using assertion for something that actually can happen with clang version change results in no meaningful error messages from reporting user. Unless they are eager to do debug rebuild and use some gdb ;)

[rlonstein]

(bump)

Any chance of this being fixed?

Occurs with clang 3.5 on Ubuntu 14.04 LTS i686 with dstep built from git master.

[jacob-carlborg]

Yes, of course. I'll see if I can get it fixed during the weekend.

[jacob-carlborg]

I haven't actually fixed this yet (I have worked improving the test infrastructure) but I can only reproduce this with libclang 3.4.x. Version 3.1-3.3 and 3.5.0 seems to be ok. This is on OS X.

[rlonstein]

I'll test on Linux and report back. Thanks.

[rlonstein]

Works as expected.