1. 24 Jun, 2021 4 commits
    • David Lechner's avatar
      py/mperrno: Add MP_ECANCELED error code. · b51ae20c
      David Lechner authored
      This is useful when binding asynchronous functions in C.
      Signed-off-by: default avatarDavid Lechner <david@pybricks.com>
      b51ae20c
    • Amir Gonnen's avatar
      unix/modffi: Add option to lock GC in callback, and cfun access. · cb332dda
      Amir Gonnen authored
      Add an optional 'lock' kwarg to callback that locks GC and scheduler.  This
      allows the callback to be invoked asynchronously in 'interrupt context',
      for example as a signal handler.
      
      Also add the 'cfun' member function to callback, that allows retrieving the
      C callback function address.  This is needed when the callback should be
      set to a struct field.
      
      See related #7373.
      Signed-off-by: default avatarAmir Gonnen <amirgonnen@gmail.com>
      cb332dda
    • Jeff Epler's avatar
      all: Fix signed shifts and NULL access errors from -fsanitize=undefined. · 413f34cd
      Jeff Epler authored
      Fixes the following (the line numbers match commit 0e87459e):
      
      ../../extmod/crypto-algorithms/sha256.c:49:19: runtime error: left shif...
      ../../extmod/moduasyncio.c:106:35: runtime error: member access within ...
      ../../py/binary.c:210:13: runtime error: left shift of negative value -...
      ../../py/mpz.c:744:16: runtime error: negation of -9223372036854775808 ...
      ../../py/objint.c:109:22: runtime error: left shift of 1 by 31 places c...
      ../../py/objint_mpz.c:374:9: runtime error: left shift of 4611686018427...
      ../../py/objint_mpz.c:374:9: runtime error: left shift of negative valu...
      ../../py/parsenum.c:106:14: runtime error: left shift of 46116860184273...
      ../../py/runtime.c:395:33: runtime error: left shift of negative value ...
      ../../py/showbc.c:177:28: runtime error: left shift of negative value -...
      ../../py/vm.c:321:36: runtime error: left shift of negative value -1```
      
      Testing was done on an amd64 Debian Buster system using gcc-8.3 and these
      settings:
      
          CFLAGS += -g3 -Og -fsanitize=undefined
          LDFLAGS += -fsanitize=undefined
      
      The introduced TASK_PAIRHEAP macro's conditional (x ? &x->i : NULL)
      assembles (under amd64 gcc 8.3 -Os) to the same as &x->i, since i is the
      initial field of the struct.  However, for the purposes of undefined
      behavior analysis the conditional is needed.
      Signed-off-by: default avatarJeff Epler <jepler@gmail.com>
      413f34cd
    • Damien George's avatar
      esp32/main: Allow MICROPY_DIR to be overridden. · 0009a7dc
      Damien George authored
      This is necessary when building a custom out-of-tree board.
      Signed-off-by: default avatarDamien George <damien@micropython.org>
      0009a7dc
  2. 23 Jun, 2021 8 commits
  3. 22 Jun, 2021 2 commits
  4. 20 Jun, 2021 1 commit
  5. 18 Jun, 2021 6 commits
  6. 17 Jun, 2021 7 commits
  7. 16 Jun, 2021 1 commit
    • Damien George's avatar
      extmod/uasyncio: Fix race with cancelled task waiting on finished task. · 514bf1a1
      Damien George authored
      This commit fixes a problem with a race between cancellation of task A and
      completion of task B, when A waits on B.  If task B completes just before
      task A is cancelled then the cancellation of A does not work.  Instead,
      the CancelledError meant to cancel A gets passed through to B (that's
      expected behaviour) but B handles it as a "Task exception wasn't retrieved"
      scenario, printing out such a message (this is because finished tasks point
      their "coro" attribute to themselves to indicate they are done, and
      implement the throw() method, but that method inadvertently catches the
      CancelledError).  The correct behaviour is for B to bounce that
      CancelledError back out.
      
      This bug is mainly seen when wait_for() is used, and in that context the
      symptoms are:
      - occurs when using wait_for(T, S), if the task T being waited on finishes
        at exactly the same time as the wait-for timeout S expires
      - task T will have run to completion
      - the "Task exception wasn't retrieved message" is printed with
        "<class 'CancelledError'>" as the error (ie no traceback)
      - the wait_for(T, S) call never returns (it's never put back on the
        uasyncio run queue) and all tasks waiting on this are blocked forever
        from running
      - uasyncio otherwise continues to function and other tasks continue to be
        scheduled as normal
      
      The fix here reworks the "waiting" attribute of Task to be called "state"
      and uses it to indicate whether a task is: running and not awaited on,
      running and awaited on, finished and not awaited on, or finished and
      awaited on.  This means the task does not need to point "coro" to itself to
      indicate finished, and also allows removal of the throw() method.
      
      A benefit of this is that "Task exception wasn't retrieved" messages can go
      back to being able to print the name of the coroutine function.
      
      Fixes issue #7386.
      Signed-off-by: default avatarDamien George <damien@micropython.org>
      514bf1a1
  8. 15 Jun, 2021 6 commits
  9. 14 Jun, 2021 2 commits
  10. 13 Jun, 2021 3 commits