If an exception's chain or context can refer to a pointer from a different
VM, a crash would typically result.
This couldn't turn up on UNIX testing because the VM is never torn
down and rebuilt like it is on hardware.
Because in the 'static' case the GeneratorObject is now fully initialized
whenever it's raised, the initialization can be dropped, which reduces
the flash size slightly.
Closes: #7565
This ensures that all builds unconditionally run makeversionhdr.py and
makemanifest.py to generate mpversion.h and frozen_content.c respectively.
This now matches the Makefile behavior, and in particular this fixes the
issue on ESP32 builds that changes in code-to-be-frozen will cause the
build to update. Both these already tools know not to touch their output
if there is no change.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
Unless MICROPY_OBJ_REPR == MICROPY_OBJ_REPR_D, these macros only work with
values and "->"/"." expressions as their sole argument. In other words,
the macros are broken with expressions which contain operations of lower
precedence than the cast operator.
Depending on situation, the old code either results in compiler error:
MP_OBJ_TO_PTR(flag ? o1 : o2) expands into "(void *)flag ? o1 : o2",
which some compiler configurations will reject (e.g. GCC -Wint-conversion
-Wint-to-pointer-cast -Werror)
Or in an incorrect address calculation:
For ptr declared as "uint8_t *" the MP_OBJ_FROM_PTR(ptr + off)
expands into ((mp_obj_t)ptr) + off, resulting in an obviously
wrong address.
Signed-off-by: Alex Riesen <alexander.riesen@cetitec.com>
This is important for literal tuples, e.g.
f"{a,b,}, {c}" --> "{}".format((a,b), (c),)
which would otherwise result in either a syntax error or the wrong result.
Fixes issue #9635.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
32-bit platforms only support a slice offset start of 24 bit max due to the
limited size of the mp_obj_array_t.free member. Similarly on 64-bit
platforms the limit is 56 bits.
This commit adds an OverflowError if the user attempts to slice a
memoryview beyond this limit.
Signed-off-by: Damien George <damien@micropython.org>
Showing 8 digits instead of 5, supporting devices with more than 1 MByte of
RAM (which is common these days). The masking was never needed, and the
related commented-out line can go.
To adhere to the contract of mp_map_lookup, namely:
MP_MAP_LOOKUP_ADD_IF_NOT_FOUND behaviour:
- returns slot, with key non-null and value=MP_OBJ_NULL if it was added
cpython actually makes sure the newly chained exception doesn't create
a cycle (even indirectly); see _PyErr_SetObject use of "Floyd's cycle
detection algo". We'll go for the simpler solution of just checking
one level deep until it's clear we need to do more.
Closes: #7414
This may help address #7409 if the underlying cause is the deterministic
volume ID. However, not all boards have working urandom (samd21
at least does not) so a couple of fallbacks are attempted when it fails.
I verified that on a pico_w, each `storage.erase_filesystem()` gives
a distinct 32-bit volume ID (pico_w's urandom can never fail)
In @micropython.native code the types of variables and expressions are
always Python objects, so they can be initialised as such. This prevents
problems with compiling optimised code like while-loops where a local may
be referenced before it is assigned to.
Signed-off-by: Damien George <damien@micropython.org>
This was previously used for the definition of NIC types, but they have
been updated to use a protocol instead.
This work was funded through GitHub Sponsors.
Signed-off-by: Jim Mussared <jim.mussared@gmail.com>
The assertion that is added here (to gc.c) fails when running this new test
if ALLOC_TABLE_GAP_BYTE is set to 0.
Signed-off-by: Jeff Epler <jepler@gmail.com>
Signed-off-by: Damien George <damien@micropython.org>
Prior to this fix the follow crash occurred. With a GC layout of:
GC layout:
alloc table at 0x3fd80428, length 32001 bytes, 128004 blocks
finaliser table at 0x3fd88129, length 16001 bytes, 128008 blocks
pool at 0x3fd8bfc0, length 2048064 bytes, 128004 blocks
Block 128003 is an AT_HEAD and eventually is passed to gc_mark_subtree.
This causes gc_mark_subtree to call ATB_GET_KIND(128004). When block 1 is
created with a finaliser, the first byte of the finaliser table becomes
0x2, but ATB_GET_KIND(128004) reads these bits as AT_TAIL, and then
gc_mark_subtree references past the end of the heap, which happened to be
past the end of PSRAM on the esp32-s2.
The fix in this commit is to ensure there is a one-byte gap after the ATB
filled permanently with AT_FREE.
Fixes issue #7116.
See also https://github.com/adafruit/circuitpython/issues/5021
Signed-off-by: Jeff Epler <jepler@gmail.com>
Signed-off-by: Damien George <damien@micropython.org>
When you want to use the valgrind memory analysis tool on MicroPython, you
can arrange to define MICROPY_DEBUG_VALGRIND to enable use of special
valgrind macros. For now, this only fixes `gc_get_ptr` so that it never
emits the diagnostic "Conditional jump or move depends on uninitialised
value(s)".
Signed-off-by: Jeff Epler <jepler@gmail.com>
This change makes it so the compiler and persistent code loader take a
mp_compiled_module_t* as their last argument, instead of returning this
struct. This eliminates a duplicate context variable for all callers of
these functions (because the context is now stored in the
mp_compiled_module_t by the caller), and also eliminates any confusion
about which context to use after the mp_compile_to_raw_code or
mp_raw_code_load function returns (because there is now only one context,
that stored in mp_compiled_module_t.context).
Reduces code size by 16 bytes on ARM Cortex-based ports.
Signed-off-by: Damien George <damien@micropython.org>
These unimplemented features may never be implemented, and having the word
"yet" there takes up space.
Signed-off-by: Damien George <damien@micropython.org>
This module is useful, but it is not always needed. Disabling it saves
several kilobytes of build size, depending on other config options.
Signed-off-by: Laurens Valk <laurens@pybricks.com>
