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

[treyhunner]

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)

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

---

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]

i'm definitively not sure but it could be because of running in inspect mode https://github.com/ethanhs/python-wasm/blob/cef91af7ded9ff456eec633f346e085a9ccb038a/browser-ui/index.js#L22 where the interpreter may still persist after the first exit() and take a different code path for init.

[tiran]

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]

Fixed in python/cpython#32212

[emmatyping]

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