[cfe-dev] Libtooling 9 segfault

[E via cfe-dev]

Some closure:

The problem ended up being the small default thread stack size in musl.
Whereas glibc typically spawns threads with 2MiB of stack, musl's default
is approximately 120KiB.

The stack gets deep when the Clang frontend is parsing complex code and
stack overflow occurs.
The solution is to increase the stack size of musl threads at build-time.
More information can be found under the "Thread stack size" heading
of this page:

https://wiki.musl-libc.org/functional-differences-from-glibc.html

Hopefully this helps anyone who comes across this problem in the future,
and I apologize if this very late reply causes problems.

Thanks.

> On Oct 31, 2019, at 03:02, E <ekmecicspam at gmail.com> wrote:
> 
> Upon further review it seems like this is a problem in Alpine Linux or musl.
> I build my program as a fully static executable in an Alpine Linux Docker container, and it segfaults.
> I spun up an Debian container and installed LLVM+Clang from the apt.llvm.org and the executable ran without segfaulting.
> The only problem is that it is now difficult to produce a fully statically linked binary.
> 
>> On Oct 30, 2019, at 10:03, E <ekmecicspam at gmail.com> wrote:
>> 
>> Hello,
>> 
>> I'm currently working on a program that uses libtooling and I've found a consistent segfault in libtooling code.
>> 
>> Details of the segfault:
>> - The program uses the MatchFinder API to match recordDecls and functionDecls. 
>> - Only reproducible when the program is compiled and ran on Linux. macOS environment does not segfault
>> - Consistently reproducible when the compile_commands.json supplied to the tool is from the nlohmann/crow repository (https://github.com/nlohmann/crow)
>> - Backtrace: https://paste.fedoraproject.org/paste/vtkefy-hrjgmyi03i22k0g/raw
>> 
>> I've considered trying to recreate a minimal working example but "slimming down" the large program I'm working on is difficult.
>> Is there any way to find the cause of this segfault without sharing source? 
>> 
>> Many thanks.
>> 
>