You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
assignee='https://github.com/methane'closed_at=<Date2021-10-21.15:41:32.700>created_at=<Date2021-10-19.05:37:58.958>labels= ['interpreter-core', '3.10', '3.11']
title='obmalloc radix tree typo in code'updated_at=<Date2021-10-21.15:41:32.700>user='https://github.com/nascheme'
I have not yet been able to reproduce methane's crash. My guess it it's not related.
An explanation of what I think the impact of this bug is:
The radix tree is used to determine if memory is from obmalloc or from the system malloc (i.e return value from address_in_range()). WIth ADDRESS_BITS set to 48, we ignore the top 16 bits of addresses. The next 10 bits are supposed to be the index into the top level node array for the radix tree. Due to the bug, we mask those and only use the bottom 8 of those 10. So, if you have virtual addresses that span more than that 8 bit range, we will index into the wrong node. That means address_in_range() could give the wrong answer. Which means you might try to free memory with the wrong malloc.
I think this is likely to be triggered only if you allocate a massive amount of memory, like 70 TB. However, triggering it would depend on how the kernel maps virtual memory to the Python process. I.e. there might be a wierd OS that gives pages at 0x7f0000000000 and then right after pages at 0x3f0000000000.