Checkout v2 subomdules #2
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Addition of RTS/CTS/RS485 capability
mimxrt10xx: Enable displayio
mimxrt10xx: Add Feather M7 1011 board config
Disable BLE file service for now
relicense nrf SPI.c to MIT
…n-import Enable _bleio adapter when _bleio is imported
cached heap buffer for neopixel_write
Arduino Nano 33 IoT support
Fix incorrect initialisation of default UART
We now correctly set the reason for the unit not being ready and always start the unit. Fixes adafruit#2567
We were trying to reset bluetooth when it was off and then trying to raise an exception without the heap.
Fix crash after empty REPL session
testing performed: * successfully store and retrieve a 500kB file on the flash * square wave output on each pin appears on o'scope * board.SPI(), board.SERIAL(), board.I2C() all construct
Fix Mac crash when waking up with an ejected CIRCUITPY
samd51 thing plus: new port
This only fixes the `import` portion. It doesn't actually change reference behavior because modules within a package could already be referenced through the parent package even though an error should have been thrown.
move red LED to D13 and make D3 lsm6ds IRQ
RFC: Use Sphinx 3 To Build Docs
The repository URL for extmod/ulab had a trailing slash, causing errors when trying to clone it. Closes adafruit#2762
The HID descriptor reported by circuitpython erroneously limited the maximum keycode to 101, which prevented circuitpython from sending a number of otherwise valid keycodes. Closes adafruit#274
Fix bad submodule path
Fix maximum keycode in keyboard HID descriptor
In order to get tags, including in submodules, we use our own fetching procedure on top of checkout@v2. A problem occuring in about 1% of jobs was that some submodules inexplicably did not have an "origin" remote configured. "git submodule sync" configures the "origin" remote in those cases. No cause for the problem was determined. Besides keeping up to date on actions/checkout, @v2 is supposed to fix a bug where "re-run" of a pull request would fail checking out the code.
jepler
pushed a commit
that referenced
this pull request
May 15, 2020
Better handle //| and do __init__.c first.
jepler
pushed a commit
that referenced
this pull request
Aug 21, 2020
jepler
added a commit
that referenced
this pull request
Aug 30, 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.
jepler
added a commit
that referenced
this pull request
Oct 1, 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 adafruit#5 0x00045496 in supervisor_background_tasks adafruit#6 0x000446e8 in background_callback_run_all adafruit#7 0x00045546 in supervisor_run_background_tasks_if_tick adafruit#8 0x0005b042 in common_hal_neopixel_write adafruit#9 0x00044c4c in clear_temp_status adafruit#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
jepler
added a commit
that referenced
this pull request
Oct 1, 2020
If `supervisor_start_terminal` is called twice in a row without `supervisor_stop_terminal`, it would lose track of a supervisor allocation. This can occur when setting the rotation of a display, including the way that a FramebufferDisplay sets rotation _AFTER_ initial construction, first with a stack like ``` #0 supervisor_start_terminal #1 in displayio_display_core_construct #2 in common_hal_framebufferio_framebufferdisplay_construct ``` and then with a stack like ``` #0 supervisor_start_terminal #1 in common_hal_framebufferio_framebufferdisplay_construct #2 in framebufferio_framebufferdisplay_make_new ``` .. without an intervening stop_terminal call. For reasons I didn't fully explore, this did not become a problem until the ability to re-allocate a freed supervisor allocation was implemented in adafruit#3482. Demonstrating the problem requires adafruit#3482 + adafruit#3497 + this PR.
jepler
added a commit
that referenced
this pull request
May 10, 2021
asan considers that memcmp(p, q, N) is permitted to access N bytes at
each of p and q, even for values of p and q that have a difference
earlier. Accessing additional values is frequently done in practice,
reading 4 or more bytes from each input at a time for efficiency, so
when completing "non_exist<TAB>" in the repl, this causes a diagnostic:
```
==16938==ERROR: AddressSanitizer: global-buffer-overflow on address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fffffffd1d0
READ of size 9 at 0x555555cd8dc8 thread T0
#0 0x7ffff726457a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
#1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301
#2 0x555555c89585 in readline_process_char ../../lib/mp-readline/readline.c:225
#3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513
#4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/unix/main.c:194
adafruit#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/main.c:673
adafruit#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/main.c:436
adafruit#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308
adafruit#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/unix/micropython-coverage+0x40bd69)
0x555555cd8dc8 is located 0 bytes to the right of global variable 'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of size 8
'import_str' is ascii string 'import '
SUMMARY: AddressSanitizer: global-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
Shadow bytes around the buggy address:
0x0aab2ab93160: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
0x0aab2ab93170: 05 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
0x0aab2ab93180: 06 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9
0x0aab2ab93190: 05 f9 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
0x0aab2ab931a0: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
=>0x0aab2ab931b0: 00 00 00 00 00 00 00 00 00[f9]f9 f9 f9 f9 f9 f9
0x0aab2ab931c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0aab2ab931d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0aab2ab931e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 f9
0x0aab2ab931f0: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 f9 f9 f9
0x0aab2ab93200: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==16938==ABORTING
```
jepler
added a commit
that referenced
this pull request
May 10, 2021
asan considers that memcmp(p, q, N) is permitted to access N bytes at
each of p and q, even for values of p and q that have a difference
earlier. Accessing additional values is frequently done in practice,
reading 4 or more bytes from each input at a time for efficiency, so
when completing "non_exist<TAB>" in the repl, this causes a diagnostic:
```
==16938==ERROR: AddressSanitizer: global-buffer-overflow on address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fffffffd1d0
READ of size 9 at 0x555555cd8dc8 thread T0
#0 0x7ffff726457a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
#1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301
#2 0x555555c89585 in readline_process_char ../../lib/mp-readline/readline.c:225
#3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513
#4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/unix/main.c:194
adafruit#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/main.c:673
adafruit#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/main.c:436
adafruit#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308
adafruit#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/unix/micropython-coverage+0x40bd69)
0x555555cd8dc8 is located 0 bytes to the right of global variable 'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of size 8
'import_str' is ascii string 'import '
SUMMARY: AddressSanitizer: global-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
Shadow bytes around the buggy address:
0x0aab2ab93160: 04 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
0x0aab2ab93170: 05 f9 f9 f9 f9 f9 f9 f9 04 f9 f9 f9 f9 f9 f9 f9
0x0aab2ab93180: 06 f9 f9 f9 f9 f9 f9 f9 06 f9 f9 f9 f9 f9 f9 f9
0x0aab2ab93190: 05 f9 f9 f9 f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9
0x0aab2ab931a0: 00 00 00 00 00 00 00 00 04 f9 f9 f9 f9 f9 f9 f9
=>0x0aab2ab931b0: 00 00 00 00 00 00 00 00 00[f9]f9 f9 f9 f9 f9 f9
0x0aab2ab931c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0aab2ab931d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0aab2ab931e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 f9
0x0aab2ab931f0: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 f9 f9 f9
0x0aab2ab93200: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
Array cookie: ac
Intra object redzone: bb
ASan internal: fe
Left alloca redzone: ca
Right alloca redzone: cb
==16938==ABORTING
```
Signed-off-by: Jeff Epler <[email protected]>
jepler
added a commit
that referenced
this pull request
May 10, 2021
asan considers that memcmp(p, q, N) is permitted to access N bytes at
each of p and q, even for values of p and q that have a difference
earlier. Accessing additional values is frequently done in practice,
reading 4 or more bytes from each input at a time for efficiency, so
when completing "non_exist<TAB>" in the repl, this causes a diagnostic:
```
==16938==ERROR: AddressSanitizer: global-buffer-overflow on
address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fff
READ of size 9 at 0x555555cd8dc8 thread T0
#0 0x7ffff726457a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
#1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301
#2 0x555555c89585 in readline_process_char ../../lib/mp-readline/re
#3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513
#4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/uni
adafruit#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/
adafruit#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/m
adafruit#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308
adafruit#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/uni
0x555555cd8dc8 is located 0 bytes to the right of global variable
'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of
size 8
'import_str' is ascii string 'import '
```
Signed-off-by: Jeff Epler <[email protected]>
jepler
added a commit
that referenced
this pull request
May 10, 2021
asan considers that memcmp(p, q, N) is permitted to access N bytes at
each of p and q, even for values of p and q that have a difference
earlier. Accessing additional values is frequently done in practice,
reading 4 or more bytes from each input at a time for efficiency, so
when completing "non_exist<TAB>" in the repl, this causes a diagnostic:
```
==16938==ERROR: AddressSanitizer: global-buffer-overflow on
address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fff
READ of size 9 at 0x555555cd8dc8 thread T0
#0 0x7ffff726457a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
#1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301
#2 0x555555c89585 in readline_process_char ../../lib/mp-readline/re
#3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513
#4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/uni
adafruit#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/
adafruit#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/m
adafruit#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308
adafruit#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/uni
0x555555cd8dc8 is located 0 bytes to the right of global variable
'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of
size 8
'import_str' is ascii string 'import '
```
Signed-off-by: Jeff Epler <[email protected]>
jepler
added a commit
that referenced
this pull request
Jun 8, 2021
asan considers that memcmp(p, q, N) is permitted to access N bytes at each
of p and q, even for values of p and q that have a difference earlier.
Accessing additional values is frequently done in practice, reading 4 or
more bytes from each input at a time for efficiency, so when completing
"non_exist<TAB>" in the repl, this causes a diagnostic:
==16938==ERROR: AddressSanitizer: global-buffer-overflow on
address 0x555555cd8dc8 at pc 0x7ffff726457b bp 0x7fffffffda20 sp 0x7fff
READ of size 9 at 0x555555cd8dc8 thread T0
#0 0x7ffff726457a (/usr/lib/x86_64-linux-gnu/libasan.so.5+0xb857a)
#1 0x555555b0e82a in mp_repl_autocomplete ../../py/repl.c:301
#2 0x555555c89585 in readline_process_char ../../lib/mp-readline/re
#3 0x555555c8ac6e in readline ../../lib/mp-readline/readline.c:513
#4 0x555555b8dcbd in do_repl /home/jepler/src/micropython/ports/uni
adafruit#5 0x555555b90859 in main_ /home/jepler/src/micropython/ports/unix/
adafruit#6 0x555555b90a3a in main /home/jepler/src/micropython/ports/unix/m
adafruit#7 0x7ffff619a09a in __libc_start_main ../csu/libc-start.c:308
adafruit#8 0x55555595fd69 in _start (/home/jepler/src/micropython/ports/uni
0x555555cd8dc8 is located 0 bytes to the right of global variable
'import_str' defined in '../../py/repl.c:285:23' (0x555555cd8dc0) of
size 8
'import_str' is ascii string 'import '
Signed-off-by: Jeff Epler <[email protected]>
jepler
pushed a commit
that referenced
this pull request
Mar 17, 2023
fix rp2040 with new shared irq usb handler
jepler
pushed a commit
that referenced
this pull request
Jan 5, 2024
Update changes of the last month for new hardware models
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In order to get tags, including in submodules, we use our own fetching procedure on top of checkout@v2.
A problem occuring in about 1% of jobs was that some submodules inexplicably did not have an "origin" remote configured. "git submodule sync" configures the "origin" remote in those cases. No cause for the problem was determined.
Besides keeping up to date on actions/checkout, @v2 is supposed to fix a bug where "re-run" of a pull request would fail checking out the code. In order to test this, I am going to cancel and re-run this PR's actions.