Skip to content

unaligned accesses in siphash24() lead to crashes on sparc #77326

Description

@DerDakon
mannequin
BPO 33145
Nosy @serhiy-storchaka, @DerDakon
PRs
  • bpo-28055: fix unaligned accesses in siphash24() #6123
  • Superseder
  • bpo-28055: pyhash's siphash24 assumes alignment of the data pointer
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = None
    closed_at = <Date 2018-03-26.16:52:24.264>
    created_at = <Date 2018-03-26.16:29:47.788>
    labels = ['3.8', '3.7', 'library']
    title = 'unaligned accesses in siphash24() lead to crashes on sparc'
    updated_at = <Date 2018-07-21.12:24:56.223>
    user = 'https://github.com/DerDakon'

    bugs.python.org fields:

    activity = <Date 2018-07-21.12:24:56.223>
    actor = 'Jeffrey.Walton'
    assignee = 'none'
    closed = True
    closed_date = <Date 2018-03-26.16:52:24.264>
    closer = 'serhiy.storchaka'
    components = ['Library (Lib)']
    creation = <Date 2018-03-26.16:29:47.788>
    creator = 'Dakon'
    dependencies = []
    files = []
    hgrepos = []
    issue_num = 33145
    keywords = []
    message_count = 2.0
    messages = ['314464', '322096']
    nosy_count = 3.0
    nosy_names = ['serhiy.storchaka', 'Jeffrey.Walton', 'Dakon']
    pr_nums = ['6123']
    priority = 'normal'
    resolution = 'duplicate'
    stage = 'resolved'
    status = 'closed'
    superseder = '28055'
    type = None
    url = 'https://bugs.python.org/issue33145'
    versions = ['Python 3.5', 'Python 3.6', 'Python 3.7', 'Python 3.8']

    Activity

    1. added
      stdlibStandard Library Python modules in the Lib/ directory
      on Mar 26, 2018
    2. serhiy-storchaka commented on Mar 26, 2018

      @serhiy-storchaka
      Member

      Actually this looks like a duplicate of bpo-28055.

    3. JeffreyWalton commented on Jul 21, 2018

      JeffreyWaltonmannequin
      Mannequin

      I know this is a bit late but I wanted to share...

      OpenCSW has a build farm with Solaris machines and Sparc hardware. The farm provides x86 and Sparc machines with Solaris 9 through 11.

      I believe OpenCSW operates in the same spirit as GCC compile farm. They welcome open source developers and upstream maintainers to help ensure packages build and run on Solaris machines.

      You can read about it at
      https://www.opencsw.org/extend-it/signup/to-upstream-maintainers/ .

      If Python is performing memory access patterns as discussed in the report then it would probably benefit the project to test on a Sparc machine with Solaris 11.

    4. transferred this issue fromon Apr 10, 2022
    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

      3.7 (EOL)end of life3.8 (EOL)end of lifestdlibStandard Library Python modules in the Lib/ directory

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions