[llvm-dev] Build failure

[Florian Hahn via llvm-dev]

> On Jan 8, 2021, at 17:50, Paul C. Anagnostopoulos via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> I'm sorry, I still don't understand. I've never seen this sort of error before. Why is the assert.td test failing in this build when it doesn't fail on my machine? Different compiled code, possibly?
> 
> Can I trust this message?
> 

Yes, you should be able to trust this message.

The bot builds LLVM with the undefined behavior sanitizer, which will insert runtime checks to catch cases of undefined behavior in the source. You need a version of LLVM that is build with the UBsan enabled to reproduce it.


> TGParser.cpp:3213:22: runtime error: reference binding to null pointer of type 'llvm::Record'
> 

Looks like the code on that line is  https://github.com/llvm/llvm-project/blob/6e2b6351d2cb1feaa88e6c92ba844ab48b4758f9/llvm/lib/TableGen/TGParser.cpp#L3213

    RecordResolver R(*CurRec);

CurRec is a pointer of type llvm::Record. The message ("runtime error: reference binding to null pointer of type 'llvm::Record’) is indicating that a null pointer is de-referenced (so it can be bound to a reference, likely RecordResolver’s constructor takes an argument `Record &`).

So there is a code path executed where CurRec is a nullptr.

> There is nothing in line 3213 that deals with the Record type.
> 
> If I try to build with the Undefined sanitizer with Visual Studio, I get:
> CMake Error at cmake/modules/HandleLLVMOptions.cmake:801 (message):
>  This sanitizer not yet supported in the MSVC environment: Undefined
> 

Looks like this is not supported with MSVC then unfortunately. The good news is if it is indeed a nullptr dereference, you can just add an assertion that `CurRec` is not nullptr to track down the issue.

Cheers,
Florian