Pin interrupt dispatching is not thread/interrupt safe

[tni]

The port interrupt pin dispatch code
if ((isfr & CORE_PIN1_BITMASK) && intFunc[1]) intFunc[1]();
compiles down to the following:

...
  16:   03a1        lsls    r1, r4, #14
  18:   d504        bpl.n   24 <portb_interrupt+0x24>
  1a:   4b1a        ldr r3, [pc, #104]  ; (84 <portb_interrupt+0x84>)
  1c:   685a        ldr r2, [r3, #4]
  1e:   b10a        cbz r2, 24 <portb_interrupt+0x24>
  20:   685b        ldr r3, [r3, #4]
  22:   4798        blx r3
...

ldr r2, [r3, #4] is a load from the intFunc[] table, loading the pin interrupt address. A NULL check is done, then the intFunc[] table load is performed again and the pointer from the table is called.

A higher priority ISR could be called between the two loads from intFunc[]. If that ISR uses detachInterrupt for the pin, NULL will be called.

[FrankBoesing]

In theory, you are right.

But the chances that somebody calls detachInterrupt inside an interrupt
is quite low, i think.

On the other hand, if you have better code that is not slower ,
repairing this would be good. Maybe in assembler to make sure that it
works for every optimization level and future GCC versions ?

[tni]

There are some uses cases. This is an issue that would be almost impossible to track down, since would occur extremely rarely. The Teensy would just hang every few weeks or months.

[PaulStoffregen]

This was fixed by #181, right?

[tni]

Fixed by #182.