ethanhs/python-wasm

Using \N after exiting and restarting results in a function signature mismatch

treyhunner opened this issue ยท 4 comments

Series of steps which reveal the bug:

  1. Click Start REPL button
  2. Type print("\N{digit nine}") and hit Enter
  3. See that 9 printed out
  4. Type exit() and hit Enter (to exit the process)
  5. Click Start REPL button again
  6. Type print("\N{digit nine}") and hit Enter
  7. Watch the process hang and an error message print to the console (this is the bug)

image

Similar series of working steps (notice no \N{...} was used)

  1. Click Start REPL button
  2. Type print("9") and hit Enter
  3. See that 9 printed out
  4. Type exit() and hit Enter (to exit the process)
  5. Click Start REPL button again
  6. Type print("9") and hint Enter
  7. See that 9 printed out

image


Context

This might seem like a strange bug to care about, but it's causing my Python pastebin site (which now runs Python code in-browser) to fail on some code examples. Specifically the "Run in Browser" button works the first time it's pressed but hangs the second time it's pressed. Here's a page that demonstrates the issue.

pmp-p commented

i'm definitively not sure but it could be because of running in inspect mode

pythonWorkerManager.run({args: ['-i', '-'], files: {}})
where the interpreter may still persist after the first exit() and take a different code path for init.

tiran commented

With some additional magic (-gsource-map linker flag and Chromium C/C++ DWARF extension) I was able to pin point the location. The issue is much more interesting than I initially thought. In fact you have found a bug in CPython.

python.js:219 Uncaught RuntimeError: null function or function signature mismatch
    at _PyUnicode_DecodeUnicodeEscapeInternal (unicodeobject.c:6493:25)
    at decode_unicode_with_escapes (string_parser.c:121:13)
    at _PyPegen_parsestr (string_parser.c:273:1)
    at strings_rule (action_helpers.c:901:20)
    at atom_rule (parser.c:14293:27)
    at primary_rule (parser.c:13916:17)
    at await_primary_rule (parser.c:13666:17)
    at factor_rule (parser.c:13542:29)
    at term_rule (parser.c:13330:17)
    at sum_rule (parser.c:13044:17)
tiran commented

I can confirm that this is fixed in the live REPL (which now is up to date!)