runtime: ubsan failure when calling through pointer to member function

Description

on ubuntu x64 using gcc-10 through gcc-12, compiled -O0 -ggdb -fsanitize=undefined

causes a runtime error when a pointer to a member function is called.

/mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/jit/phase.h:100:10: runtime error: member access within address 0x7fbeb726e070 which does not point to an object of type 'Phase'
0x7fbeb726e070: note: object has invalid vptr
 ff c9 c3 90  f3 0f 1e fa 55 48 89 e5  41 55 41 54 53 48 83 ec  18 48 89 7d d8 48 8b 45  d8 48 83 7d
              ^~~~~~~~~~~~~~~~~~~~~~~
              invalid vptr

The relevant top ~10 frames are below.

I suspect that one of the three+ pointers in the expression

  (comp->*action)()

may point to de-allocated or scribbled-upon storage. I can not tell if it is the memory pointed to by

  1. this (eg, a CompilerPhase)
  2. this->comp (eg, a Compiler)
  3. this->action (a closure/thunk of some kind, with a vptr / vtbl, plus pointer to the function itself, namely Compiler::fgAddInternal()

The attached program reproduces the ubsan runtime error message when one of the instances has been deleted.

I do not see this behavior with clang+ubsan, using clang 10-clang-14

The invocation of gcc -fsanitize=address has put in at least 7 checks for this call.

==========frames================

3  0x00007fbeb726e6f0 in CompilerPhase::DoPhase (this=0x7fffffffb840)
    at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/jit/phase.h:100
100	        (comp->*action)();
(gdb) up
#4  0x00007fbeb72740eb in Phase::Run (this=0x7fffffffb840) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/jit/phase.cpp:61
61	    PhaseStatus status = DoPhase();
(gdb) where
#0  __ubsan::ScopedReport::~ScopedReport (this=this@entry=0x7fffffffb500, __in_chrg=<optimized out>)
    at ../../../../src/libsanitizer/ubsan/ubsan_diag.cpp:388
#1  0x00007ffff7995438 in HandleDynamicTypeCacheMiss (Data=<optimized out>, Pointer=140457093292144, Hash=<optimized out>, Opts=...)
    at ../../../../src/libsanitizer/ubsan/ubsan_handlers_cxx.cpp:81
#2  0x00007ffff799578f in __ubsan::__ubsan_handle_dynamic_type_cache_miss (Data=<optimized out>, Pointer=<optimized out>, 
    Hash=<optimized out>) at ../../../../src/libsanitizer/ubsan/ubsan_handlers_cxx.cpp:87
#3  0x00007fbeb726e6f0 in CompilerPhase::DoPhase (this=0x7fffffffb840)
    at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/jit/phase.h:100
#4  0x00007fbeb72740eb in Phase::Run (this=0x7fffffffb840) at /mnt/robhenry/dotnet/clang11.a/runtime/src/coreclr/jit/phase.cpp:61
#5  0x00007fbeb726e979 in DoPhase (_compiler=0x5555556c6318, _phase=PHASE_MORPH_ADD_INTERNAL, 
    _action=(void (Compiler::*)(Compiler * const)) 0x7fbeb74bb758 <Compiler::fgAddInternal()>)

Reproduction Steps

This program generates the same ubsan runtime error. The small program reference through a deleted object ubsan.txt

Expected behavior

no runtime errors

Actual behavior

see runtime errors

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

/cc @AaronRobinsonMSFT

category:correctness theme:intrinsics skill-level:beginner cost:small impact:small

About this issue

  • Original URL
  • State: open
  • Created 2 years ago
  • Comments: 15 (14 by maintainers)

Most upvoted comments

That was quite a while ago, and the hacky infrastructure I threw together to compile dotnet core runtime with different g++ invocations may have fallen apart. I’ll see what I can do.

On Mon, Jun 5, 2023 at 11:37 AM Kunal Pathak @.***> wrote:

@RobertHenry6bev https://github.com/RobertHenry6bev - can you please confirm the full command you used to repro this?

— Reply to this email directly, view it on GitHub https://github.com/dotnet/runtime/issues/73927#issuecomment-1577280356, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABBLLY4MBSBNFSSXPJKJRXDXJYRNTANCNFSM56RB5MXQ . You are receiving this because you were mentioned.Message ID: @.***>