Incorrect setting of class.base.type in some examples
Port, board and/or hardware
unix/standard port, PiZero2 board, but irrelevant to this issue
MicroPython version
MicroPython v1.25.0 on 2025-04-30; linux [GCC 14.2.0] version
Reproduction
Here are some lines from native module example code.
examples/natmod/btree/btree_c.chas:btree_type.base.type = (void*)&mp_fun_table.type_type;examples/natmod/re/re.chas:match_type.base.type = (void*)&mp_fun_table.type_type;examples/natmod/deflate/deflate.chas:deflateio_type.base.type = mp_fun_table.type_type;examples/natmod/framebuf/framebuf.chas:mp_type_framebuf.base.type = (void*)&mp_type_type;
The last is a bit confusing. Because all of these files #include "py/dynruntime.h", it gets macro-expanded to:
mp_type_framebuf.base.type = (void*)&(*mp_fun_table.type_type);
And so patterns the same as the third option. That struct field holds a pointer to the variable that in the interpreter is called mp_type_type, but which is not directly visible to the dynamic native modules.
So cases 3 and 4 are setting the base.type to a (const mp_obj_type_t *), whose value is &mp_type_type (this is the const type object defined in py/objtype.c, not the macro defined in py/dynruntime.h).
Whereas cases 1 and 2 are setting the base.type to a pointer to a struct field that holds such a (const mp_obj_type_t *). They're one pointer level further removed. This is just not noticed because they are cast to (void *).
I believe that cases 1 and 2 are mistakes, and that they should be following the pattern in case 3 or case 4. Am I right?
Expected behaviour
No response
Observed behaviour
See code analysis above. Examples as-is compile and run without issue; but I think this is just because the type is being treated as opaque and not being dereferenced.
Additional Information
No, I've provided everything above.
Code of Conduct
Yes, I agree
segfault with improper use of super()
Port, board and/or hardware
unix, coverage build
MicroPython version
MicroPython v1.26.0-preview.387.ge4e97f5aa7.dirty on 2025-07-20; linux [GCC 12.2.0] version
Reproduction
Run the following code:
import framebuf
class FB(framebuf.FrameBuffer):
def __init__(self, n):
self = n
super().__init__(bytearray(2 * n * n), n, n, framebuf.RGB565)
fb = FB(n=3)
Expected behaviour
super() should not segfault.
Observed behaviour
crash in native_base_init_wrapper
Program received signal SIGSEGV, Segmentation fault.
0x00005555556120c7 in native_base_init_wrapper (n_args=5, args=0x7fffffffd6c0,
kw_args=0x7fffffffd510) at ../../py/objtype.c:91
91 instance_count_native_bases(self->base.type, &native_base);
(gdb) p self
$1 = (mp_obj_instance_t *) 0x7
Additional Information
This is a minimized version of a script produced by fuzzing micropython.
Code of Conduct
Yes, I agree