pathological_tests_library .......***Failed

[juhp]

It is not a priority problem but just want to record that the pathological_tests_library is failing on fedora.

[juhp]

Ah I see it is some python issue:

4/9 Testing: pathological_tests_library
4/9 Test: pathological_tests_library
Command: "/usr/bin/python3.14" "/var/home/petersen/fedora/cmark/BUILD/cmark-0.31.2-build/cmark-0.31.2/test/pathological_tests.py" "--library-dir" "/var/home/petersen/fedora/cmark/BUILD/cmark-0.31.2-build/cmark-0.31.2/redhat-linux-build/src"
Directory: /var/home/petersen/fedora/cmark/BUILD/cmark-0.31.2-build/cmark-0.31.2/redhat-linux-build/testdir
"pathological_tests_library" start time: Feb 17 15:01 +08
Output:
----------------------------------------------------------
Testing pathological cases:
Traceback (most recent call last):
  File "<string>", line 1, in <module>
    from multiprocessing.forkserver import main; main(10, 12, ['__main__'], **{'sys_path': ['/var/home/petersen/fedora/cmark/BUILD/cmark-0.31.2-build/cmark-0.31.2/test', '/usr/lib64/python314.zip', '/usr/lib64/python3.14', '/usr/lib64/python3.14/lib-dynload', '/usr/lib64/python3.14/site-packages', '/usr/lib/python3.14/site-packages'], 'main_path': '/var/home/petersen/fedora/cmark/BUILD/cmark-0.31.2-build/cmark-0.31.2/test/pathological_tests.py', 'authkey_r': 14})
                                                 ~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/forkserver.py", line 217, in main
    spawn.import_main_path(main_path)
    ~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/spawn.py", line 307, in import_main_path
    _fixup_main_from_path(main_path)
    ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/spawn.py", line 297, in _fixup_main_from_path
    main_content = runpy.run_path(main_path,
                                  run_name="__mp_main__")
  File "<frozen runpy>", line 287, in run_path
  File "<frozen runpy>", line 98, in _run_module_code
  File "<frozen runpy>", line 88, in _run_code
  File "/var/home/petersen/fedora/cmark/BUILD/cmark-0.31.2-build/cmark-0.31.2/test/pathological_tests.py", line 25, in <module>
    cmark = CMark(prog=args.program, library_dir=args.library_dir)
  File "/var/home/petersen/fedora/cmark/BUILD/cmark-0.31.2-build/cmark-0.31.2/test/cmark.py", line 85, in __init__
    cmark = CDLL(libpath)
                 ^^^^^^^
UnboundLocalError: cannot access local variable 'libpath' where it is not associated with a value
Traceback (most recent call last):
  File "/var/home/petersen/fedora/cmark/BUILD/cmark-0.31.2-build/cmark-0.31.2/test/pathological_tests.py", line 202, in <module>
    run_tests()
    ~~~~~~~~~^^
  File "/var/home/petersen/fedora/cmark/BUILD/cmark-0.31.2-build/cmark-0.31.2/test/pathological_tests.py", line 159, in run_tests
    p.start()
    ~~~~~~~^^
  File "/usr/lib64/python3.14/multiprocessing/process.py", line 121, in start
    self._popen = self._Popen(self)
                  ~~~~~~~~~~~^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/context.py", line 224, in _Popen
    return _default_context.get_context().Process._Popen(process_obj)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/context.py", line 300, in _Popen
    return Popen(process_obj)
  File "/usr/lib64/python3.14/multiprocessing/popen_forkserver.py", line 35, in __init__
    super().__init__(process_obj)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/popen_fork.py", line 20, in __init__
    self._launch(process_obj)
    ~~~~~~~~~~~~^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/popen_forkserver.py", line 51, in _launch
    self.sentinel, w = forkserver.connect_to_new_process(self._fds)
                       ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/forkserver.py", line 106, in connect_to_new_process
    connection.answer_challenge(
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~^
            wrapped_client, self._forkserver_authkey)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib64/python3.14/multiprocessing/connection.py", line 970, in answer_challenge
    message = connection.recv_bytes(256)         # reject large message
  File "/usr/lib64/python3.14/multiprocessing/connection.py", line 222, in recv_bytes
    buf = self._recv_bytes(maxlength)
  File "/usr/lib64/python3.14/multiprocessing/connection.py", line 447, in _recv_bytes
    buf = self._recv(4)
  File "/usr/lib64/python3.14/multiprocessing/connection.py", line 412, in _recv
    chunk = read(handle, to_read)
ConnectionResetError: [Errno 104] Connection reset by peer
<end of output>
Test time =   0.72 sec
----------------------------------------------------------
Test Failed.
"pathological_tests_library" end time: Feb 17 15:01 +08
"pathological_tests_library" time elapsed: 00:00:00
----------------------------------------------------------

Anyway not a big deal - currently I just disable the tests on fedora, though suppose I could just disable this one.

It is not a regression wrt to 0.31.1, but perhaps since 0.30 (I can easily version bissect if that helps) - or perhaps it is python.

[jgm]

It would be good to pinpoint the issue. It could be due to a change in the python infrastructure, too, but if you could bisect that would be great.

[juhp]

I tried and the error also occurs with 0.30.3 now. So I think something changed on the python side.

So I compared and the test succeeds on Fedora 42 (F42) but fails on Fedora 43 (F43):

F42 has python3-3.13.11
F43 has python3-3.14.2 (and F44 will have python3-3.14.3)

So that is my main "suspect".

The GH Ubuntu image in CI currently has Python 3.12.3
(Looks like even Ubuntu 26.04 may only ship Python 3.13, shrug)

Sorry I don't really have time to dig deeper ;-(

[jgm]

Claude has the following diagnosis:

This is indeed a Python 3.14 change. Python 3.14 changed the default multiprocessing start method on Linux from "fork" to "forkserver".

With "fork", child processes inherited the parent's memory (including already-parsed arguments and initialized objects), so top-level code didn't need to be guarded. With "forkserver", the child process re-imports the script, which means the top-level code in pathological_tests.py (argument parsing, CMark() construction) runs again — but without the original command-line arguments. That's why libpath ends up unbound in cmark.py.

The fix is one of:

1. Guard the top-level code in pathological_tests.py with if __name__ == "__main__": (the proper/recommended fix). The run_tests() call and argument parsing at module level (around line 202 and line 25) should be inside this guard. This is standard practice for any script using multiprocessing.

2. Explicitly set the start method to "fork" early in the script as a quick workaround:

   import multiprocessing
   multiprocessing.set_start_method("fork")

   Though this just papers over the real issue and "fork" is being deprecated for good reasons (it's unsafe with threads).

The root cause is that cmark's pathological_tests.py has argument parsing and CMark initialization at the top level without an if __name__ == "__main__": guard — which worked fine with "fork" but breaks with "forkserver" or "spawn".

[jgm]

I'm sorry - Python is a mystery to me. Hopefully someone else can fix this.