Skip to content

Commit a76df78

Browse files
committed
[lldb] Make the NSSet formatter faster and less prone to infinite recursion
Right now to get the 'NSSet *` pointer value we first derefence it and then take the address of the result. Beside being inefficient this potentially can cause an infinite recursion if the `pointer` value we get is a pointer of a type that the TypeSystem can't derefence. If the pointer is for example some form of `void *` that the dynamic type resolution can't resolve to an actual type, then the `Derefence` call goes back to asking the formatters how to reference it. If the NSSet formatter then checks if it's an NSSet variation under the hood then we just end infinitely often recursion. In practice this seems to happen with some form of Builtin.RawPointer we get from a NSDictionary in Swift. FWIW, no other formatter is doing the same deref->addressOf as here and there doesn't seem to be any specific reason to do so in the git history (it's just part of the initial formatter commit) Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D101537
1 parent 5fbea82 commit a76df78

File tree

1 file changed

+4
-16
lines changed

1 file changed

+4
-16
lines changed

lldb/source/Plugins/Language/ObjC/NSSet.cpp

Lines changed: 4 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -444,18 +444,12 @@ bool lldb_private::formatters::NSSetISyntheticFrontEnd::Update() {
444444
if (!valobj_sp)
445445
return false;
446446
m_exe_ctx_ref = valobj_sp->GetExecutionContextRef();
447-
Status error;
448-
if (valobj_sp->IsPointerType()) {
449-
valobj_sp = valobj_sp->Dereference(error);
450-
if (error.Fail() || !valobj_sp)
451-
return false;
452-
}
453-
error.Clear();
454447
lldb::ProcessSP process_sp(valobj_sp->GetProcessSP());
455448
if (!process_sp)
456449
return false;
457450
m_ptr_size = process_sp->GetAddressByteSize();
458-
uint64_t data_location = valobj_sp->GetAddressOf() + m_ptr_size;
451+
uint64_t data_location = valobj_sp->GetValueAsUnsigned(0) + m_ptr_size;
452+
Status error;
459453
if (m_ptr_size == 4) {
460454
m_data_32 = new DataDescriptor_32();
461455
process_sp->ReadMemory(data_location, m_data_32, sizeof(DataDescriptor_32),
@@ -728,18 +722,12 @@ lldb_private::formatters::
728722
if (!valobj_sp)
729723
return false;
730724
m_exe_ctx_ref = valobj_sp->GetExecutionContextRef();
731-
Status error;
732-
if (valobj_sp->IsPointerType()) {
733-
valobj_sp = valobj_sp->Dereference(error);
734-
if (error.Fail() || !valobj_sp)
735-
return false;
736-
}
737-
error.Clear();
738725
lldb::ProcessSP process_sp(valobj_sp->GetProcessSP());
739726
if (!process_sp)
740727
return false;
741728
m_ptr_size = process_sp->GetAddressByteSize();
742-
uint64_t data_location = valobj_sp->GetAddressOf() + m_ptr_size;
729+
uint64_t data_location = valobj_sp->GetValueAsUnsigned(0) + m_ptr_size;
730+
Status error;
743731
if (m_ptr_size == 4) {
744732
m_data_32 = new D32();
745733
process_sp->ReadMemory(data_location, m_data_32, sizeof(D32),

0 commit comments

Comments
 (0)