Another segfault in gc_heap::get_region_plan_gen_num for a frozen object

[MichalStrehovsky]

Introduced by enabling regions. Similar to #63778 but won't be fixed with the pull request in flight.

reproNative.exe!WKS::gc_heap::get_region_gen_num(unsigned char * obj) Line 11252  C++
reproNative.exe!WKS::gc_heap::object_gennum(unsigned char * o) Line 10991    C++
reproNative.exe!WKS::GCHeap::WhichGeneration(Object * object) Line 43434    C++
reproNative.exe!HndWriteBarrierWorker(OBJECTHANDLE__ * handle, Object * value) Line 578  C++
reproNative.exe!HndWriteBarrier(OBJECTHANDLE__ * handle, Object * objref) Line 22  C++
reproNative.exe!HndAssignHandle(OBJECTHANDLE__ * handle, Object * objref) Line 47  C++
reproNative.exe!HndCreateHandle(HandleTable * hTable, unsigned int uType, Object * object, unsigned __int64 lExtraInfo) Line 314    C++
reproNative.exe!GCHandleStore::CreateDependentHandle(Object * primary, Object * secondary) Line 49      C++
reproNative.exe!RhpHandleAllocDependent(Object * pPrimary, Object * pSecondary) Line 26      C++
reproNative.exe!S_P_CoreLib_System_Runtime_RuntimeImports__RhHandleAllocDependent() Line 235    Unknown

We’re in get_region_gen_num asking about a frozen object again.

I’ve tried adding an early out to object_gennum (if !is_in_heap_range, return max_generation) and that seems to do the trick, but maybe I’ve just introduced a GC hole, so I’ll better leave that to the GC team.

[ghost]

Tagging subscribers to this area: @dotnet/gc
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Introduced by enabling regions. Similar to #63778 but won't be fixed with the pull request in flight.

reproNative.exe!WKS::gc_heap::get_region_gen_num(unsigned char * obj) Line 11252  C++
reproNative.exe!WKS::gc_heap::object_gennum(unsigned char * o) Line 10991    C++
reproNative.exe!WKS::GCHeap::WhichGeneration(Object * object) Line 43434    C++
reproNative.exe!HndWriteBarrierWorker(OBJECTHANDLE__ * handle, Object * value) Line 578  C++
reproNative.exe!HndWriteBarrier(OBJECTHANDLE__ * handle, Object * objref) Line 22  C++
reproNative.exe!HndAssignHandle(OBJECTHANDLE__ * handle, Object * objref) Line 47  C++
reproNative.exe!HndCreateHandle(HandleTable * hTable, unsigned int uType, Object * object, unsigned __int64 lExtraInfo) Line 314    C++
reproNative.exe!GCHandleStore::CreateDependentHandle(Object * primary, Object * secondary) Line 49      C++
reproNative.exe!RhpHandleAllocDependent(Object * pPrimary, Object * pSecondary) Line 26      C++
reproNative.exe!S_P_CoreLib_System_Runtime_RuntimeImports__RhHandleAllocDependent() Line 235    Unknown

We’re in get_region_gen_num asking about a frozen object again.

I’ve tried adding an early out to object_gennum (if !is_in_heap_range, return max_generation) and that seems to do the trick, but maybe I’ve just introduced a GC hole, so I’ll better leave that to the GC team.

Author:	MichalStrehovsky
Assignees:	-
Labels:	area-GC-coreclr
Milestone:	-

[Maoni0]

thanks for discovering this. we should put the check in WhichGeneration since object_gennum is only used by the GC internally for objects not on the ro segments (where frozen objects are kept).

unsigned int GCHeap::WhichGeneration (Object* object)
{
#ifdef FEATURE_BASICFREEZE
    if (!((o < g_gc_highest_address) && (o >= g_gc_lowest_address)))
    {
        return max_generation;
    }
#endif //FEATURE_BASICFREEZE
    gc_heap* hp = gc_heap::heap_of ((uint8_t*)object);
    unsigned int g = hp->object_gennum ((uint8_t*)object);
    dprintf (3, ("%Ix is in gen %d", (size_t)object, g));
    return g;
}