circuitpython/shared-bindings/busio
Jeff Epler f94d3e86cf
UART: Don't allocate the object so early
This object has a finalizer, so once it's no longer referenced, GC can
call that finalizer and then deallocate the storage.

In the case of a failure during construction (e.g., when checking
`validate_obj_is_free_pin_or_none`) this will happen on an incompletely
initialized structure.  On samd, in particular, a newly allocated object
(with construct never called) appears to be valid, so GC collecting it
causes deinit() to do things, leading to a hard fault.

The double creation of the UART object was necessary specifically so that
the second allocation would fail.  Probably there were other (single
call) ways to make it fail, but this was the easiest / the one discovered
in real life.

Closes: #5493
2021-12-01 20:54:39 -06:00
..
I2C.c Initial broadcom port for Raspberry Pi 2021-11-22 14:54:44 -08:00
I2C.h run code formatting script 2021-03-15 19:27:36 +05:30
SPI.c Initial broadcom port for Raspberry Pi 2021-11-22 14:54:44 -08:00
SPI.h Update all implementations of common_hal_busio_spi_read to honor write_value 2021-08-18 10:20:40 -05:00
UART.c UART: Don't allocate the object so early 2021-12-01 20:54:39 -06:00
UART.h run code formatting script 2021-03-15 19:27:36 +05:30
__init__.c Initial broadcom port for Raspberry Pi 2021-11-22 14:54:44 -08:00
__init__.h Initial merge of micropython v1.9.2 into circuitpython 2.0.0 (in development) master. 2017-08-25 22:17:07 -04:00