python - 是否可以恢复损坏的 “interned” 字节对象

Question

众所周知，那个小bytes -objects 被 CPython 自动“interned”(类似于 intern 字符串的函数)。 更正:如 explained @abernert 它更像是整数池而不是内部字符串。

是否可以在内部字节对象被“实验性”第三方库损坏后恢复它们，或者是重新启动内核的唯一方法？

概念证明可以使用 Cython 功能(Cython>=0.28)完成:

%%cython
def do_bad_things():
   cdef bytes b=b'a'
   cdef const unsigned char[:] safe=b  
   cdef char *unsafe=<char *> &safe[0]   #who needs const and type-safety anyway?
   unsafe[0]=98                          #replace through `b`

或者按照@jfs 的建议通过 ctypes :

import ctypes
import sys
def do_bad_things():
    b = b'a'; 
    (ctypes.c_ubyte * sys.getsizeof(b)).from_address(id(b))[-2] = 98

显然，通过滥用 C 功能， do_bad_things更改不可变(或 CPython 认为)对象 b'a'至 b'b'因为这个 bytes -object 被实习，我们可以看到之后发生了不好的事情:

>>> do_bad_things() #b'a' means now b'b'
>>> b'a'==b'b'  #wait for a surprise  
True
>>> print(b'a') #another one
b'b'

可以恢复/清除字节对象池，以便 b'a'意味着 b'a'再次？

一个小小的旁注:似乎不是每个 bytes -创建进程正在使用这个池。例如:

>>> do_bad_things()
>>> print(b'a')
b'b'
>>> print((97).to_bytes(1, byteorder='little')) #ord('a')=97
b'a'

Answer 1

Python 3 不像 bytes 那样实习 str 对象。相反，它像使用 int 一样保留了它们的静态数组。

这在幕后是非常不同的。不利的一面是，这意味着没有要操作的表(带有 API)。从好的方面来说，这意味着如果你能找到静态数组，你就可以修复它，就像修复整数一样，因为数组索引和字符串的字符值应该是相同的。

如果您查看 bytesobject.c ，则会在顶部声明该数组:

static PyBytesObject *characters[UCHAR_MAX + 1];

...然后，例如，在 PyBytes_FromStringAndSize 中:

if (size == 1 && str != NULL &&
    (op = characters[*str & UCHAR_MAX]) != NULL)
{
#ifdef COUNT_ALLOCS
    one_strings++;
#endif
    Py_INCREF(op);
    return (PyObject *)op;
}

请注意，该数组是 static ，因此无法从该文件外部访问它，并且它仍在对对象进行引用计数，因此调用者(甚至解释器中的内部内容，更不用说您的 C API 扩展)无法判断有什么特别之处在。

所以，没有“正确”的方法来清理它。

但是，如果你想变得 hacky ......

如果您有对任何单字符字节的引用，并且您知道它应该是哪个字符，则可以到达数组的开头，然后清理整个内容。

除非你搞砸的比你想象的还要多，否则你可以构建一个单字符的 bytes 并减去它应该是的字符。 PyBytes_FromStringAndSize("a", 1) 将返回应该是 'a' 的对象，即使它碰巧实际持有 'b' 。我们怎么知道？因为这正是您要解决的问题。

实际上，可能有一些方法可以让事情变得更糟……这些似乎都不太可能，但为了安全起见，让我们使用一个比 a 更不容易被破坏的字符，例如 \x80 :

PyBytesObject *byte80 = (PyBytesObject *)PyBytes_FromStringAndSize("\x80", 1);
PyBytesObject *characters = byte80 - 0x80;

唯一的另一个警告是，如果您尝试使用 ctypes 而不是 C 代码从 Python 执行此操作，则需要一些额外的小心，1 但由于您没有使用 ctypes ，所以我们不必担心。

所以，现在我们有了一个指向 characters 的指针，我们可以遍历它。我们不能只是删除对象来“取消实习”它们，因为这会使任何引用它们的人都感到沮丧，并可能导致段错误。但我们没有必要。表中的任何对象，我们都知道它应该是什么—— characters[i] 应该是一个单字符的 bytes ，其一个字符是 i 。所以只需将它设置回那个，循环如下:

for (size_t char i=0; i!=UCHAR_MAX; i++) {
    if (characters[i]) {
        // do the same hacky stuff you did to break the string in the first place
    }
}

这里的所有都是它的。

好吧，除了编译 2

幸运的是，在交互式解释器中，每个完整的顶级语句都是它自己的编译单元，因此……在运行修复程序后，您应该可以输入任何新行。

但是您导入的模块必须编译，而您的字符串却损坏了？你可能搞砸了它的常数。除了强制重新编译和重新导入每个模块之外，我想不出一个好的方法来清理它。

1. 编译器可能会在你的 b'\x80' 参数进入 C 调用之前将它变成错误的东西。你会惊讶于所有你认为你正在传递 c_char_p 的地方，它实际上是神奇地与 bytes 相互转换。使用 POINTER(c_uint8) 可能更好。

2. 如果你编译了一些包含 b'a' 的代码，consts 数组应该有一个对 b'a' 的引用，这将得到修复。但是，由于 bytes 对编译器来说是不可变的，如果它知道 b'a' == b'b' ，它实际上可能会存储指向 b'b' 单例的指针，原因与 123456 is 123456 为真，在这种情况下，修复 b'a' 可能实际上并不能解决问题。