SP: Remove user thread noexcept uses that aren't explicitly allowed

XMLWordPrintableJSON

    • Type: Task
    • Resolution: Fixed
    • Priority: Major - P3
    • 8.2.0-rc0
    • Affects Version/s: None
    • Component/s: None
    • None
    • Server Programmability
    • Fully Compatible
    • Programmability 2025-01-06, Programmability 2025-01-20, Programmability 2025-02-03, Programmability 2025-02-17, Programmability 2025-03-03, Programmability 2025-03-17
    • 200
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      As a fallout from recent now-public CVEs (linked to this issue) we'd like to ensure that we avoid any crashes on user/connection threads due to a noexcept boundary being triggered. We have recently updated our documentation to have a much stricter policy on when noexcept should be used at all, but have decided to separate out noexcepts on user threads as a targeted fix for teams to execute.

      For every noexcept in code owned by your team identified by this spreadsheet, please:

      1. Check if the noexcept could be triggered on a user thread.
      2. If yes to 1, check if the noexcept qualifies to remain based on the documentation's criteria.
      3. If no to 2, remove the noexcept. If it is necessary – in some places a crash is truly and unequivocally preferable – add new logic that explicitly generates behavior that was being implicitly triggered by noexcept. If you were relying on crash behavior, strongly consider downgrading instead to a tassert, meaning that crashes only happen in test environment. Using a tassert would be much more preferable from a user safety standpoint. 

       

            Assignee:
            Ryan Berryhill
            Reporter:
            Blake Oler
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: