Skip to content

Merge latest CircuitPython changes (6.0.0-rc.1) #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 217 commits into from
Nov 3, 2020

Conversation

ecasadod
Copy link
Member

@ecasadod ecasadod commented Nov 3, 2020

No description provided.

astrobokonon and others added 30 commits September 19, 2020 13:38
ap_rssi is a bound method, which I'm not keen on, but it works
still need to figure out the bound method business
Forgot to make it a property!
When allocations were freed in a different order from the reverse of how they were allocated (leaving holes), the heap would get into an inconsistent state, eventually resulting in crashes.

free_memory() relies on having allocations in order, but allocate_memory() did not guarantee that: It reused the first allocation with a NULL ptr without ensuring that it was between low_address and high_address. When it belongs to a hole in the allocated memory, such an allocation is not really free for reuse, because free_memory() still needs its length.

Instead, explicitly mark allocations available for reuse with a special (invalid) value in the length field. Only allocations that lie between low_address and high_address are marked that way.
This requires recovering the pointer of the allocation, which could be done by adding up neighbor lengths, but the simpler way is to stop NULLing it out in the first place and instead mark an allocation as freed by the client by setting the lowest bit of the length (which is always zero in a valid length).
tannewt and others added 25 commits October 30, 2020 12:03
Add new board to nrf port: holyiot_nrf52840
Removed ignore PA30 PA31 in order to allow using them as pinout
improve USB CDC disconnect/reconnect checking
Merge 6.0.x bugfixes to main
workflows: Fix typo that broke builds while trying to upload stubs
The stubs directory is called `circuitpython-stubs`, not `stubs`.
Need to request zip to recurse, because it is not the default
Use correct stubs directory name
Currently translated at 99.2% (838 of 844 strings)

Translation: CircuitPython/main
Translate-URL: https://hosted.weblate.org/projects/circuitpython/main/es/
Currently translated at 100.0% (844 of 844 strings)

Translation: CircuitPython/main
Translate-URL: https://hosted.weblate.org/projects/circuitpython/main/sv/
.../boards/bdmicro_vina_d51: PAD updates for better resource flexibility
Fixing remaining stub mypy issues + run check-stubs to CI
ESP32S2: Fix parallel strip issue with Neopixels
@ecasadod ecasadod merged commit f94cc09 into BHDynamics:main Nov 3, 2020
ecasadod pushed a commit that referenced this pull request Nov 10, 2020
A crash like the following occurs in the unix port:
```
Program received signal SIGSEGV, Segmentation fault.
0x00005555555a2d7a in mp_obj_module_set_globals (self_in=0x55555562c860 <ulab_user_cmodule>, globals=0x55555562c840 <mp_module_ulab_globals>) at ../../py/objmodule.c:145
145	    self->globals = globals;
(gdb) up
#1  0x00005555555b2781 in mp_builtin___import__ (n_args=5, args=0x7fffffffdbb0) at ../../py/builtinimport.c:496
496	                mp_obj_module_set_globals(outer_module_obj,
(gdb)
#2  0x00005555555940c9 in mp_import_name (name=824, fromlist=0x555555621f10 <mp_const_none_obj>, level=0x1) at ../../py/runtime.c:1392
1392	    return mp_builtin___import__(5, args);
```

I don't understand how it doesn't happen on the embedded ports, because
the module object should reside in ROM and the assignment of self->globals
should trigger a Hard Fault.

By checking VERIFY_PTR, we know that the pointed-to data is on the heap
so we can do things like mutate it.
ecasadod pushed a commit that referenced this pull request Nov 10, 2020
ecasadod pushed a commit that referenced this pull request Nov 10, 2020
It was incorrect to NULL out the pointer to our heap allocated buffer in
`reset`, because subsequent to framebuffer_reset, but while
the heap was still active, we could call `get_bufinfo` again,
leading to a fresh allocation on the heap that is about to be destroyed.

Typical stack trace:
```
#1  0x0006c368 in sharpdisplay_framebuffer_get_bufinfo
#2  0x0006ad6e in _refresh_display
#3  0x0006b168 in framebufferio_framebufferdisplay_background
#4  0x00069d22 in displayio_background
#5  0x00045496 in supervisor_background_tasks
#6  0x000446e8 in background_callback_run_all
#7  0x00045546 in supervisor_run_background_tasks_if_tick
#8  0x0005b042 in common_hal_neopixel_write
#9  0x00044c4c in clear_temp_status
#10 0x000497de in spi_flash_flush_keep_cache
adafruit#11 0x00049a66 in supervisor_external_flash_flush
adafruit#12 0x00044b22 in supervisor_flash_flush
adafruit#13 0x0004490e in filesystem_flush
adafruit#14 0x00043e18 in cleanup_after_vm
adafruit#15 0x0004414c in run_repl
adafruit#16 0x000441ce in main
```
When this happened -- which was inconsistent -- the display would keep
some heap allocation across reset which is exactly what we need to avoid.

NULLing the pointer in reconstruct follows what RGBMatrix does, and that
code is a bit more battle-tested anyway.

If I had a motivation for structuring the SharpMemory code differently,
I can no longer recall it.

Testing performed: Ran my complicated calculator program over multiple
iterations without observing signs of heap corruption.

Closes: adafruit#3473
ecasadod pushed a commit that referenced this pull request Nov 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.