Regression with MicroPython file handles on 1.20

[amotl]

Hi there,

Thibault reported to me that he found a regression on version 1.20 with the file open/close/contextmanager. I will outline this by providing respective examples which clearly show the regression.

Pycom MicroPython 1.18

Pycom MicroPython 1.18.3 [v1.8.6-849-e0915e1] on 2019-10-06; LoPy4 with ESP32
>>> with open('/flash/test.txt', 'w') as f:
...     f.write('ABCD')
...     
...     
... 
4
>>> f.close()
>>> 

Pycom MicroPython 1.20

Pycom MicroPython 1.20.2.rc6 [v1.11-01f49f7] on 2020-02-28; LoPy4 with ESP32
Pybytes Version: 1.3.1
>>> with open('/flash/test.txt', 'w') as f:
...     f.write('ABC')
...     
...     
... 
3
>>> f
<>
>>> f.close()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: '' object has no attribute 'close'
>>> f.__class__
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

CPython 3.x also shows the same behavior as Pycom MicroPython 1.18, so the filehandle can indeed be accessed outside the scope of the context manager. While I haven't been aware of that before, it really looks like a regression on 1.20.

With kind regards, Andreas.

[amotl]

On one of my FiPy's, the core panic already happens when printing the representation of the file handle f to the REPL just after leaving the context manager.

>>> f
Guru Meditation Error: Core  1 panic'ed (LoadProhibited). Exception was unhandled.

The decoded core dump from where this panic happens is:

==================== CURRENT THREAD STACK =====================
#0  mp_obj_print_helper (print=0x3f410c78 <mp_sys_stdout_print>, o_in=0x3f986a20, kind=PRINT_REPR) at ../py/obj.c:69
#1  0x40107ecf in mp_builtin___repl_print__ (o=0x3f986a20) at ../py/modbuiltins.c:451
#2  0x40101a0c in fun_builtin_1_call (self_in=0x3f41055c <mp_builtin___repl_print___obj>, n_args=1, n_kw=0, args=0x3ffd9b18) at ../py/objfun.c:70
#3  0x400fde30 in mp_call_function_n_kw (fun_in=0x3f41055c <mp_builtin___repl_print___obj>, n_args=1, n_kw=0, args=0x3ffd9b18) at ../py/runtime.c:624
#4  0x40109de4 in mp_execute_bytecode (code_state=0x3ffd9b00, inject_exc=0x0) at ../py/vm.c:919
#5  0x40101b1f in fun_bc_call (self_in=<optimized out>, n_args=<optimized out>, n_kw=0, args=0x0) at ../py/objfun.c:287
#6  0x400fde30 in mp_call_function_n_kw (fun_in=0x3f986a30, n_args=0, n_kw=0, args=0x0) at ../py/runtime.c:624
#7  0x400fde5d in mp_call_function_0 (fun=0x3f986a30) at ../py/runtime.c:598
#8  0x400e149c in parse_compile_execute (source=0x3ffd9c40, input_kind=MP_PARSE_SINGLE_INPUT, exec_flags=22) at ../lib/utils/pyexec.c:103
#9  0x400e1713 in pyexec_friendly_repl () at ../lib/utils/pyexec.c:549
#10 0x400e01a4 in TASK_Micropython (pvParameters=<optimized out>) at mptask.c:341

As the core panic originates from just printing the representation of the file handle variable f to the REPL, this clearly does not show the root cause. However, it might help others to investigate the issue.