Skip to content

Emscripten: Get test suite passing #127146

Closed

Description

@hoodmane

First I'd like to get the test suite to run all the way through, then to pass.

cc @freakboy3742

Update 2025/01/30

Emscripten 4.0.2 has fixes for all of the file system bugs I've looked into. There are still problems with nonblocking I/O which I haven't looked into.

Emscripten PRs:

Linked PRs

Activity

  1. added a commit that references this issue on Dec 16, 2024
  2. added 2 commits that reference this issue on Dec 17, 2024
  3. added 5 commits that reference this issue on Jan 6, 2025
  4. added a commit that references this issue on Jan 6, 2025
  5. added 2 commits that reference this issue on Jan 6, 2025
  6. added 8 commits that reference this issue on Jan 8, 2025
  7. added a commit that references this issue on Jan 27, 2025
  8. added a commit that references this issue on Jan 28, 2025
  9. added 3 commits that reference this issue on Jan 28, 2025
  10. added a commit that references this issue on Jan 28, 2025
  11. added 2 commits that reference this issue on Jan 30, 2025
  12. added a commit that references this issue on Mar 16, 2025
  13. added a commit that references this issue on Mar 17, 2025
  14. added a commit that references this issue on Mar 24, 2025
  15. added a commit that references this issue on Mar 24, 2025
  16. added a commit that references this issue on Apr 1, 2025
  17. added a commit that references this issue on Apr 4, 2025
  18. added a commit that references this issue on May 20, 2025
  19. added a commit that references this issue on May 20, 2025
  20. added a commit that references this issue on May 20, 2025
  21. added a commit that references this issue on May 20, 2025
  22. added a commit that references this issue on May 26, 2025
  23. added 5 commits that reference this issue on Jun 17, 2025
  24. added a commit that references this issue on Jun 18, 2025
  25. added a commit that references this issue on Jun 18, 2025
  26. added a commit that references this issue on Jun 18, 2025
  27. added a commit that references this issue on Jun 18, 2025
  28. added 2 commits that reference this issue on Jun 18, 2025
  29. added a commit that references this issue on Jun 18, 2025
  30. added a commit that references this issue on Jun 18, 2025
  31. added a commit that references this issue on Jun 18, 2025
  32. added a commit that references this issue on Jun 18, 2025
  33. freakboy3742 commented on Jun 18, 2025

    @freakboy3742
    Contributor

    A status update: As of the state of #135635 (based off cb39410), I'm seeing the following problems when running with Emscripten 4.0.10, on macOS.

    I get an error building libffi if the Emscripten build script is run using Python 3.14. This is caused by #135648; a workaround is described on that ticket.

    I'm getting a hard interpreter crash (stack overflow) unless I add skip_emscripten_stack_overflow to:

    • test_syntax.py, SyntaxErrorTestCase.test_error_on_parser_stack_overflow() (L3232)
    • test_exceptions.py, ExceptionTests.test_recursion_normalizing_exception() (L1449)
    • test_exceptions.py, ExceptionTests.test_recursion_in_except_handler() (L1525)

    I then get 6 failures on a full python.sh -m test -v -uall --rerun --single-process -W test run:

    • test_os; this is 100% reliable for me on macOS.
    Test failures
    ======================================================================
    FAIL: test_mode (test.test_os.MakedirTests.test_mode)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/rkm/projects/python/cpython/Lib/test/test_os.py", line 1932, in test_mode
        self.assertEqual(os.stat(parent).st_mode & 0o777, 0o775)
        ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AssertionError: 493 != 509
    
    • test_pathlib; this is an intermittent failure (maybe 50% of the time); it looks like there might be a granularity issue with the time check being performed.
    Test failures
    ======================================================================
    FAIL: test_touch_common (test.test_pathlib.test_pathlib.PathTest.test_touch_common)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/rkm/projects/python/cpython/Lib/test/test_pathlib/test_pathlib.py", line 2347, in test_touch_common
        self.assertGreaterEqual(st.st_mtime_ns, old_mtime_ns)
        ~~~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AssertionError: 1750218792835000000 not greater than or equal to 1750218792836000000
    
    • test_shutil; this looks like it might be a macOS filesystem detail leaking through?
    Test failures
    
    ======================================================================
    ERROR: test_move_dir_caseinsensitive (test.test_shutil.TestMove.test_move_dir_caseinsensitive)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/rkm/projects/python/cpython/Lib/test/test_shutil.py", line 2910, in test_move_dir_caseinsensitive
        self.assertTrue(os.path.isdir(dst_dir))
        ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^
    AssertionError: False is not true
    
    During handling of the above exception, another exception occurred:
    
    Traceback (most recent call last):
      File "/Users/rkm/projects/python/cpython/Lib/test/test_shutil.py", line 2912, in test_move_dir_caseinsensitive
        os.rmdir(dst_dir)
        ~~~~~~~~^^^^^^^^^
    FileNotFoundError: [Errno 44] No such file or directory: '/Users/rkm/projects/python/cpython/cross-build/wasm32-emscripten/build/python/build/test_python_worker_721831æ/TMPVBL6GF7G'
    
    • test_tarfile; this looks like it's a limit that might be different; it might be macOS related?
    Test failures
    
    ======================================================================
    ERROR: test_realpath_limit_attack (test.test_tarfile.TestExtractionFilters.test_realpath_limit_attack) [fully_trusted]
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/rkm/projects/python/cpython/Lib/test/test_tarfile.py", line 3842, in test_realpath_limit_attack
        self.expect_exception(KeyError)
        ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^
      File "/Users/rkm/projects/python/cpython/Lib/test/test_tarfile.py", line 3702, in expect_exception
        raise self.raised_exception
      File "/Users/rkm/projects/python/cpython/Lib/test/test_tarfile.py", line 3623, in check_context
        tar.extractall(self.destdir, filter=filter)
        ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/Users/rkm/projects/python/cpython/Lib/tarfile.py", line 2415, in extractall
        self._extract_one(tarinfo, path, set_attrs=not tarinfo.isdir(),
        ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                          numeric_owner=numeric_owner,
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                          filter_function=filter_function)
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/Users/rkm/projects/python/cpython/Lib/tarfile.py", line 2524, in _extract_one
        self._handle_fatal_error(e)
        ~~~~~~~~~~~~~~~~~~~~~~~~^^^
      File "/Users/rkm/projects/python/cpython/Lib/tarfile.py", line 2518, in _extract_one
        self._extract_member(tarinfo, os.path.join(path, tarinfo.name),
        ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                             set_attrs=set_attrs,
                             ^^^^^^^^^^^^^^^^^^^^
                             numeric_owner=numeric_owner,
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                             filter_function=filter_function,
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                             extraction_root=path)
                             ^^^^^^^^^^^^^^^^^^^^^
      File "/Users/rkm/projects/python/cpython/Lib/tarfile.py", line 2609, in _extract_member
        self.makedir(tarinfo, targetpath)
        ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^
      File "/Users/rkm/projects/python/cpython/Lib/tarfile.py", line 2645, in makedir
        os.mkdir(targetpath, 0o700)
        ~~~~~~~~^^^^^^^^^^^^^^^^^^^
    OSError: [Errno 37] Filename too long: '/Users/rkm/projects/python/cpython/cross-build/wasm32-emscripten/build/python/build/test_python_worker_517188æ/@test_42_tmpæ-tardir/outerdir/dest/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd/dddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddddd'
    
    • test_unicode_file_functions; this looks like it might be a macOS filesystem detail leaking through?
    Test failures
    ======================================================================
    FAIL: test_normalize (test.test_unicode_file_functions.UnicodeFileTests.test_normalize)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/rkm/projects/python/cpython/Lib/test/test_unicode_file_functions.py", line 138, in test_normalize
        self._apply_failure(open, name)
        ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
      File "/Users/rkm/projects/python/cpython/Lib/test/test_unicode_file_functions.py", line 89, in _apply_failure
        with self.assertRaises(expected_exception) as c:
             ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
    AssertionError: FileNotFoundError not raised
    
    ======================================================================
    FAIL: test_normalize (test.test_unicode_file_functions.UnicodeNFCFileTests.test_normalize)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/rkm/projects/python/cpython/Lib/test/test_unicode_file_functions.py", line 138, in test_normalize
        self._apply_failure(open, name)
        ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
      File "/Users/rkm/projects/python/cpython/Lib/test/test_unicode_file_functions.py", line 89, in _apply_failure
        with self.assertRaises(expected_exception) as c:
             ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
    AssertionError: FileNotFoundError not raised
    
    ======================================================================
    FAIL: test_normalize (test.test_unicode_file_functions.UnicodeNFDFileTests.test_normalize)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/rkm/projects/python/cpython/Lib/test/test_unicode_file_functions.py", line 138, in test_normalize
        self._apply_failure(open, name)
        ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
      File "/Users/rkm/projects/python/cpython/Lib/test/test_unicode_file_functions.py", line 89, in _apply_failure
        with self.assertRaises(expected_exception) as c:
             ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
    AssertionError: FileNotFoundError not raised
    
    ======================================================================
    FAIL: test_normalize (test.test_unicode_file_functions.UnicodeNFKCFileTests.test_normalize)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/rkm/projects/python/cpython/Lib/test/test_unicode_file_functions.py", line 138, in test_normalize
        self._apply_failure(open, name)
        ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
      File "/Users/rkm/projects/python/cpython/Lib/test/test_unicode_file_functions.py", line 89, in _apply_failure
        with self.assertRaises(expected_exception) as c:
             ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
    AssertionError: FileNotFoundError not raised
    
    ======================================================================
    FAIL: test_normalize (test.test_unicode_file_functions.UnicodeNFKDFileTests.test_normalize)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/Users/rkm/projects/python/cpython/Lib/test/test_unicode_file_functions.py", line 138, in test_normalize
        self._apply_failure(open, name)
        ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
      File "/Users/rkm/projects/python/cpython/Lib/test/test_unicode_file_functions.py", line 89, in _apply_failure
        with self.assertRaises(expected_exception) as c:
             ~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^
    AssertionError: FileNotFoundError not raised
    

    As soon as #135635 merges, I'll run the same tests on the buildbot to see what is repeatable there.

  34. added 2 commits that reference this issue on Jun 18, 2025
  35. added a commit that references this issue on Jun 18, 2025
  36. added 2 commits that reference this issue on Jun 18, 2025
  37. added a commit that references this issue on Jun 19, 2025
  38. added a commit that references this issue on Jun 19, 2025
  39. added a commit that references this issue on Jun 19, 2025
  40. added 5 commits that reference this issue on Jun 19, 2025
  41. added a commit that references this issue on Jun 19, 2025
  42. freakboy3742 commented on Jun 19, 2025

    @freakboy3742
    Contributor

    On the buildbot machine, the situation is a lot better - there's only one failure, in test_os:

    ======================================================================
    FAIL: test_mode (test.test_os.MakedirTests.test_mode)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/emscripten/cpython/Lib/test/test_os.py", line 1931, in test_mode
        self.assertEqual(os.stat(parent).st_mode & 0o777, 0o775)
        ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AssertionError: 493 != 509
    
    ----------------------------------------------------------------------
    

    Again, this is a 100% reliable failure.

  43. added a commit that references this issue on Jun 20, 2025
  44. added a commit that references this issue on Jun 21, 2025
  45. added a commit that references this issue on Jun 21, 2025
  46. added a commit that references this issue on Jun 21, 2025
  47. added a commit that references this issue on Jul 3, 2025
  48. freakboy3742 commented on Jul 9, 2025

    @freakboy3742
    Contributor

    Current status - 3 failing tests:

    test_pydoc:

    ======================================================================
    FAIL: test_apropos_empty_doc (test.test_pydoc.test_pydoc.PydocImportTest.test_apropos_empty_doc)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/emscripten/buildarea/3.x.rkm-emscripten.emscripten/build/Lib/test/test_pydoc/test_pydoc.py", line 1316, in test_apropos_empty_doc
        self.assertIn('walkpkg', stdout.getvalue())
        ~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    AssertionError: 'walkpkg' not found in '...
    

    test_netrc - (see #136227 for some discussion)

    ======================================================================
    ERROR: test_security (test.test_netrc.NetrcTestCase.test_security)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/emscripten/buildarea/3.x.rkm-emscripten.emscripten/build/Lib/test/test_netrc.py", line 292, in test_security
        nrc = netrc.netrc()
      File "/home/emscripten/buildarea/3.x.rkm-emscripten.emscripten/build/Lib/netrc.py", line 88, in __init__
        self._parse(file, fp, default_netrc)
        ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/emscripten/buildarea/3.x.rkm-emscripten.emscripten/build/Lib/netrc.py", line 155, in _parse
        self._security_check(fp, default_netrc, self.hosts[entryname][0])
        ~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
      File "/home/emscripten/buildarea/3.x.rkm-emscripten.emscripten/build/Lib/netrc.py", line 164, in _security_check
        raise NetrcParseError(
            f"~/.netrc file owner ({fowner}) does not match"
            f" current user ({user})")
    netrc.NetrcParseError: ~/.netrc file owner (uid 1002) does not match current user (uid 0) (None, line None)
    
    ----------------------------------------------------------------------
    Ran 23 tests in 0.037s
    
    FAILED (errors=1, skipped=1)
    

    test_sqlite3

    ======================================================================
    FAIL: test_open_undecodable_uri (test.test_sqlite3.test_dbapi.OpenTests.test_open_undecodable_uri)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/emscripten/buildarea/3.x.rkm-emscripten.emscripten/build/Lib/test/test_sqlite3/test_dbapi.py", line 702, in test_open_undecodable_uri
        self.assertTrue(os.path.exists(path))
        ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
    AssertionError: False is not true
    
    ======================================================================
    FAIL: test_open_with_undecodable_path (test.test_sqlite3.test_dbapi.OpenTests.test_open_with_undecodable_path)
    ----------------------------------------------------------------------
    Traceback (most recent call last):
      File "/home/emscripten/buildarea/3.x.rkm-emscripten.emscripten/build/Lib/test/test_sqlite3/test_dbapi.py", line 659, in test_open_with_undecodable_path
        self.assertTrue(os.path.exists(path))
        ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
    AssertionError: False is not true
    
    ----------------------------------------------------------------------
    Ran 494 tests in 2.625s
    
    FAILED (failures=2, skipped=12)
    
  49. hoodmane commented on Jul 10, 2025

    @hoodmane
    ContributorAuthor

    So it looks like the netrc problem is that we don't copy the uid over from the native FS to the Emscripten FS. Maybe we can fix it.

  50. hoodmane commented on Jul 10, 2025

    @hoodmane
    ContributorAuthor

    getuid() in Emscripten is defined here:
    https://github.com/emscripten-core/emscripten/blob/main/system/lib/libc/emscripten_syscall_stubs.c#L153
    to always return 0, but with weak linkage so we could override it if we want.

  51. added 4 commits that reference this issue on Jul 10, 2025
  52. hoodmane commented on Jul 10, 2025

    @hoodmane
    ContributorAuthor

    I can't reproduce the test_apropos_empty_doc failure. Opened #136510 to put back the test skip for test_open_undecodable_uri and opened #136509 to fix the netrc bug.

  53. freakboy3742 commented on Jul 11, 2025

    @freakboy3742
    Contributor

    I can't reproduce the test_apropos_empty_doc test on my machine either - but interestingly, looking at the code, it's another test that uses chmod... I wonder if it might be part of the same cluster of issues.

  54. hoodmane commented on Jul 11, 2025

    @hoodmane
    ContributorAuthor

    Opened upstream issue about test_open_undecodable_uri: the problem is that the UTF8ArrayToString() function used to decode the path argument to openat() has separate code paths for <= 16 bytes and > 16 bytes strings and they don't do the same thing:
    emscripten-core/emscripten#24690

  55. added 8 commits that reference this issue on Jul 12, 2025
  56. added a commit that references this issue on Jul 13, 2025
  57. added a commit that references this issue on Jul 13, 2025
  58. added a commit that references this issue on Jul 13, 2025
  59. added 2 commits that reference this issue on Jul 14, 2025
  60. added a commit that references this issue on Jul 16, 2025
  61. added a commit that references this issue on Jul 16, 2025
  62. added 3 commits that reference this issue on Jul 16, 2025
  63. added a commit that references this issue on Jul 16, 2025
  64. added a commit that references this issue on Jul 16, 2025
  65. added a commit that references this issue on Jul 16, 2025
  66. added a commit that references this issue on Jul 16, 2025
  67. added a commit that references this issue on Jul 16, 2025
  68. added a commit that references this issue on Jul 16, 2025
  69. added 3 commits that reference this issue on Jul 16, 2025
  70. freakboy3742 commented on Jul 17, 2025

    @freakboy3742
    Contributor

    After a lot of hair pulling, I've tracked down the source of the test_pydoc.test_apropos_empty_doc failure - it's umasking again.

    When running locally, or in a code checkout on the CI machine, the test directory has 755 permissions, which L1313 of the test masks down to 655.

    However, under CI, the test folder has 700 permissions. This means the created directory isn't visible, and so it doesn't appear in the return data.

    The only reasons I can think that the test would generate 700 permissions are:

    1. A leak of test conditions from another test, or
    2. A bug in the Emscripten implementation of umask

    Or possibly a combination of 1 and 2. Given that we already know that 2 is at least partially true already, I think I'm comfortable making this a test skip (with an open ticket for CPython to resolve umask issues once Emscripten has corrected those APIs).

  71. added a commit that references this issue on Jul 17, 2025
  72. added a commit that references this issue on Jul 17, 2025
  73. added a commit that references this issue on Jul 17, 2025
  74. added a commit that references this issue on Jul 17, 2025
  75. freakboy3742 commented on Jul 17, 2025

    @freakboy3742
    Contributor

    Closing .... because all the tests are now passing!!

    Image
  76. added 14 commits that reference this issue on Aug 4, 2025
  77. added a commit that references this issue on Aug 15, 2025
  78. added a commit that references this issue on Aug 17, 2025
  79. added 14 commits that reference this issue on Aug 19, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions