SIGABRT boost::filesystem::filesystem_error

[TTimo]

Got the following crash:

terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
  what():  boost::filesystem::status: File name too long: "/home/timo/Valve/UnrealEngine/Engine/Source/ThirdParty/OpenSubdiv/3.0.2/opensubdiv/hbr/../hbr/../hbr/[20 more lines worth of this]
./hbr/../hbr/../hbr/../hbr/../hbr/../hbr/../hbr/../hbr/libgprims/stitchInternal.h"

Latest Linux x64 build.

Crashed after I tried 'validate include directives' in the new project setup:

[mlangkabel]

Thanks for reporting. We could not reproduce the crash on either, 32 bit Linux or 64 bit Linux by just entering a very/../very long path into the Additional Include Paths listbox.

Can you please look at your project settings and try to find out which of your Global Include Paths (must be global, I guess, because your non-globals are empty on the screenshot) may produce /home/timo/Valve/UnrealEngine/Engine/Source/ThirdParty/OpenSubdiv/3.0.2/opensubdiv/hbr/../hbr/../hbr/[20 more lines worth of this] ./hbr/../hbr/../hbr/../hbr/../hbr/../hbr/../hbr/../hbr/? Just ignore the last folder and file name. They get appended at a later step.

Are there any symlinks involved?

[egraether]

I had a look at this.

I suspect that the include validation algorithm is somehow ending up in an endless recursion. I couldn't reproduce this with relative include paths or relative include directives. I canonicalized the processed paths with 2017.3.78, which could potentially fix this.

Also disabled the include directive validation for compilation database source groups, since it does not make use of header search paths within the compile commands, so the results are misleading.

[egraether]

Fixed with 2018.2.50
Could finally be reproduced and fixed by canonicalising the processed paths. Not sure why the previous fix did not work.