GitLab

Multiprocessing and curses don't mix well.

Symptoms: Things no longer work after field initialization.

It is known that terminal input may sometimes echo and be buffered, usually after rapidly spamming the keyboard. But this is a more persistent problem that appears to have been solved. If you do have random errors like these under realistic conditions, please open a new bug.

This may still be an issue on untested platforms, which is why the workarounds can be manually enabled or disabled.

Manually enable or disable

There are two configuration variables to mess with:

• fix14a in options in cursescfg
• fix14b in init-field in enginecfg

fix14a set to on resets the terminal to shell mode during field initialization. This is necessary on affected platforms.
fix14a set to off does not reset the terminal. This can be slightly better on platforms not affected by this issue.

The issue seems to arise when the worker processes get terminated while the terminal is in program mode.

On some platforms, fix14a set to on doesn't help. In that case you may need to uncomment fix14b in enginecfg which keeps the children from being terminated.

Old tests

This is an old issue that has been fixed, completely disappeared, and then it came back with 0.5.18.

Issue #27 (closed) describes how this was apparently never an issue, but as noted it's back.

The fix14a configuration option was introduced in 0.5.27 and replaces the command line options --fix14-on and --fix14-off.

Tests during development of 0.5.18: https://gitlab.com/oskog97/anonymine-testing/blob/master/test-0.5.18