<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <br>
    <br>
    <div class="moz-cite-prefix">On 5/22/24 10:51 AM,
      <a class="moz-txt-link-abbreviated" href="mailto:mark.yagnatinsky@barclays.com">mark.yagnatinsky@barclays.com</a> wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CH3PR12MB7619677F346E734C75AA6086F9EB2@CH3PR12MB7619.namprd12.prod.outlook.com">
      
      <meta name="Generator" content="Microsoft Word 15 (filtered medium)">
      <style>@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        mso-ligatures:standardcontextual;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}div.WordSection1
        {page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal">Ah, didn’t realize P4 is default; that
          makes sense.<o:p></o:p></p>
        <p class="MsoNormal">So I should not even be trying to derive
          omens from that.<o:p></o:p></p>
        <p class="MsoNormal">So I guess only the assignee would know
          whether or not the status is closer to<o:p></o:p></p>
        <p class="MsoNormal">“I was going to work on that next week”
          versus<o:p></o:p></p>
        <p class="MsoNormal">“I totally forgot about that thing, and am
          about to forget about it again”<o:p></o:p></p>
        <p class="MsoNormal">I’m quite sure he’s on this list and will
          hopefully read the advocacy section of my email.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Um.  I feel awkward writing this paragraph
          because you know how OpenJDK works much better than I do, so
          it feels a bit silly to argue with you about it.  But.  Um.<o:p></o:p></p>
        <p class="MsoNormal">When you say “this is not the place to ask
          for fixes” …<o:p></o:p></p>
        <p class="MsoNormal">I was under the impression that “asking for
          fixes” actually does provide value, and not all of that value
          can be replaced by merely providing fixes.<o:p></o:p></p>
        <p class="MsoNormal">In particular, asking for fixes gives
          maintainers a vague sense of how often people in the “real
          world” tend to run into an issue, which in turn informs how
          much “cost” is worth spending on addressing it.<o:p></o:p></p>
        <p class="MsoNormal">(Where “cost” could mean things like “time”
          and also things like “this makes trickier and hence harder to
          maintain”.)<o:p></o:p></p>
        <p class="MsoNormal">In fact, I was under the impression that
          OpenJDK is slightly hostile to “big” fixes by “outsiders”
          because of the worry that there’s now a big/complicated chunk
          of code that no one inside the project understands and yet the
          project is responsible for, and the original author might
          never be heard from again.</p>
      </div>
    </blockquote>
    <br>
    I think that is mainly the case for some new feature.<br>
    Or if you want to take some existing feature / functionality and
    re-write it in a different way.<br>
    <br>
    True "bug fixes" to existing code are generally welcome, although
    that isn't the same as saying<br>
    they are quickly accepted.  They still need review and testing, and
    if the area is sensitive or complex that<br>
    can be quite time consuming on all ends of it. Which would all also
    be the case even if an<br>
    experienced contributor provided the fix.<br>
    <br>
    -phil.<br>
    <br>
    <blockquote type="cite" cite="mid:CH3PR12MB7619677F346E734C75AA6086F9EB2@CH3PR12MB7619.namprd12.prod.outlook.com">
      <div class="WordSection1">
        <p class="MsoNormal"><o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p class="MsoNormal">Anyway, thanks a bunch for responding; I
          was worried that no one would.<o:p></o:p></p>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
            <p class="MsoNormal"><b><span style="mso-ligatures:none">From:</span></b><span style="mso-ligatures:none"> Philip Race
                <a class="moz-txt-link-rfc2396E" href="mailto:philip.race@oracle.com"><philip.race@oracle.com></a>
                <br>
                <b>Sent:</b> Wednesday, May 22, 2024 11:54 AM<br>
                <b>To:</b> Yagnatinsky, Mark : IT (NYK)
                <a class="moz-txt-link-rfc2396E" href="mailto:mark.yagnatinsky@barclays.com"><mark.yagnatinsky@barclays.com></a>;
                <a class="moz-txt-link-abbreviated" href="mailto:core-libs-dev@openjdk.org">core-libs-dev@openjdk.org</a><br>
                <b>Subject:</b> Re: stack overflow in regex engine<o:p></o:p></span></p>
          </div>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <p><span style="font-size:12.0pt;color:#010101">CAUTION: This
            email originated from outside our organisation -
            <a href="mailto:philip.race@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">philip.race@oracle.com</a>
            Do not click on links, open attachments, or respond unless
            you recognize the sender and can validate the content is
            safe.</span><o:p></o:p></p>
        <p class="MsoNormal" style="margin-bottom:12.0pt">P4 is the
          default JBS priority, so sometimes it just means no one
          figured out the true priority.<br>
          But in general P4 bugs could be open for years, or even never
          get fixed.<br>
          The priority is also partially an assessment of where it falls
          as a priority for the JDK developers.<br>
          A user of JDK may have an entirely different perspective.<br>
          And that's why there are vendors who provide support for JDK.
          They can also arrange the backports you need.<br>
          But that's not done here. Here is where you come to
          participate and contribute fixes, not ask for fixes.<br>
          So my suggestion is to raise it via your support channel to
          your particular vendor who provided your binary.<br>
          <br>
          -phil<o:p></o:p></p>
        <div>
          <p class="MsoNormal">On 5/21/24 8:46 PM, <a href="mailto:mark.yagnatinsky@barclays.com" moz-do-not-send="true" class="moz-txt-link-freetext">
              mark.yagnatinsky@barclays.com</a> wrote:<o:p></o:p></p>
        </div>
        <blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
          <p class="MsoNormal">(Sorry about my previous “do I need to
            subscribe?” email; in retrospect that was needless noise.)<o:p></o:p></p>
          <p class="MsoNormal">The purpose of this email is twofold:
            first, inquire about the status of ticket filed a few years
            ago, and second to point out some non-obvious reasons why it
            might be slightly more serious than it seems.<o:p></o:p></p>
          <p class="MsoNormal">The ticket is this one <a href="https://clicktime.symantec.com/15t5ekSGXorRH53n7q6GJ?h=e9ZmDJOAdCkeHz_PXjDgZiyUdvJmTZTTcGvZoAULMmE=&u=https://bugs.openjdk.org/browse/JDK-8260866" moz-do-not-send="true">
              https://bugs.openjdk.org/browse/JDK-8260866</a> (stack
            overflow in regex matching quantified alternation)<o:p></o:p></p>
          <p class="MsoNormal">The priority is listed as P4, which I
            guess means something like “medium” (more important than p5,
            but less than p3)<o:p></o:p></p>
          <p class="MsoNormal">It also has a specific person assigned,
            which seems vaguely encouraging, but no updates at all in
            the years since it’s been created, which seems less
            encouraging.<o:p></o:p></p>
          <p class="MsoNormal">It was seemingly never once discussed on
            this mailing list, not even when it was first filed.<o:p></o:p></p>
          <p class="MsoNormal">As an outsider, I’m not quite sure how to
            interpret all these various omens and turn them into guesses
            about its eventual fate.<o:p></o:p></p>
          <p class="MsoNormal">Will it remain unfixed for another decade
            or two?  Will it be fixed in a few months, but then never
            backported to old versions?  Something else?  No one knows?<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">That concludes the status inquiry.  Now
            on to the advocacy.  Some bugs are annoying, but once you
            hit them, you can work around them by changing your code so
            it does not trigger the bug.<o:p></o:p></p>
          <p class="MsoNormal">Note the phrase “your code” above.  This
            is much more awkward to do if the bug triggered by
            third-party code you got from maven central or something.<o:p></o:p></p>
          <p class="MsoNormal">At that point your options are to either
            ask the third party library to work around it, or else fork
            the dependency (which is not well supported by mainstream
            build tools (or maybe I’m just using them wrong)).<o:p></o:p></p>
          <p class="MsoNormal">In this case, regular expressions are so
            ubiquitous that the bug is quite plausibly more likely to be
            triggered by some third party dependency than by code you
            own.<o:p></o:p></p>
          <p class="MsoNormal">That was the case for me today: after
            spending hours trying to track down a stack overflow error I
            found the offending regex in a third party library.<o:p></o:p></p>
          <p class="MsoNormal">The good news is that for the kinds of
            inputs we need to handle, it is indeed easy to substitute a
            much simpler regex that would avoid the issue.<o:p></o:p></p>
          <p class="MsoNormal">The bad news is that it’s not my code, so
            I can’t.  I could petition the maintainers of the library,
            but this is not great because:<o:p></o:p></p>
          <p class="MsoNormal">First, maybe the version I’m on is not
            longer even supported, and newer versions are not
            compatible,<o:p></o:p></p>
          <p class="MsoNormal">Second, it may take them a while to fix
            it, and third, it is wasteful (and inelegant) to have
            workarounds slowly percolate throughout the Java ecosystem
            instead of fixing the problem at the root.<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">The other annoying thing here is that
            even when you have “enough” stack space to avoid crashing,
            using it may not be quite “free”.<o:p></o:p></p>
          <p class="MsoNormal">For instance, project loom’s foundational
            premise seems to be that “most threads have oversized
            stacks; we can have more threads if we start off with small
            stacks and grow them only when needed”.<o:p></o:p></p>
          <p class="MsoNormal">This would be false when the thread in
            question uses a regex with quantified alternation.<o:p></o:p></p>
          <p class="MsoNormal">(Since many Loom threads will be based on
            the same Runnable, it’s a pretty safe bet that if one of
            them uses this feature, many will, so you can’t assume it
            will “average out”.)<o:p></o:p></p>
          <p class="MsoNormal">There are other reasons besides loom to
            be low on stack space; maybe you’re using some crazy
            framework(s) that like(s) to have call stacks that are crazy
            deep.<o:p></o:p></p>
          <p class="MsoNormal">Or maybe you’re running with -Xss set
            pretty low.  Or you passed a small value for stack space to
            the Thread constructor.<o:p></o:p></p>
          <p class="MsoNormal">Or maybe none of these things are true,
            but in most operating systems a thread stack costs “real”
            memory in proportion to its high-watermark, so even a SINGLE
            heavy regex in the lifetime of a thread is tantamount to a
            memory leak of hundreds of kilobytes.<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Practicalities aside, I don’t like it
            when code consumes “surprising” types of resources, or
            surprising amounts of them.<o:p></o:p></p>
          <p class="MsoNormal">For instance, you wouldn’t expect a
            sorting function to spawn threads behind your back, unless
            it was called “parallel sort” or something like that.<o:p></o:p></p>
          <p class="MsoNormal">You wouldn’t expect it to allocate
            multi-gigabyte arrays, nor to perform I/O.<o:p></o:p></p>
          <p class="MsoNormal">Similarly, most functions need only O(1)
            stack space, so this tends to be the default assumption
            unless the docs explicitly call out “this thing might throw
            stack overflows at you so make sure you have plenty of stack
            space”<o:p></o:p></p>
          <p class="MsoNormal">Some need a bit more… for instance, I
            would not be surprised if a regex need stack space in
            proportion to the depth of the parse tree of the regex.<o:p></o:p></p>
          <p class="MsoNormal">But stack space in proportion to the
            length of the string being matched is the kind of thing that
            I’d hope gets called out in those @implNotes thingies, or
            better yet fixed.<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Even people who know that regex matching
            can sometimes take exponential time may naively assume that
            regex matching would not consume O(n) stack space, where n
            is the input length.<o:p></o:p></p>
          <p class="MsoNormal">What’s worse, not only does it indeed
            consume stack space linear in the length of the input, but
            the constant hidden by the O() notation is itself pretty
            scary.<o:p></o:p></p>
          <p class="MsoNormal">For instance, consider the regex that
            caused my troubles today:<o:p></o:p></p>
          <p class="MsoNormal"><a href="https://clicktime.symantec.com/15t5jadYzRY1h1shfPVQv?h=nT81oCo1qZ8nsQ8sI9SyBtH8DOuudlSAMaXkeKhYmgU=&u=https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java%23L63" moz-do-not-send="true">https://github.com/apache/camel/blob/main/core/camel-support/src/main/java/org/apache/camel/support/ObjectHelper.java#L63</a><o:p></o:p></p>
          <p class="MsoNormal">After getting rid of extra escaping and
            also double-escaping caused by java not having “raw”
            strings, we’re left with this:<o:p></o:p></p>
          <p class="MsoNormal" style="background:white"><span style="font-size:10.0pt;font-family:"Courier New";color:#067D17;background:#EDFCED;mso-ligatures:none">,(?!(?:[^(,]|[^)],[^)])+\))</span><o:p></o:p></p>
          <p class="MsoNormal">(I find the above hard to read; the regex
            I would have replaced it with, if it had been “our” code is
            simply a single comma.)<o:p></o:p></p>
          <p class="MsoNormal">Anyway, I tried creating a Scanner with
            the delimiter above and looping through all the tokens in
            the string that originally caused the crash.<o:p></o:p></p>
          <p class="MsoNormal">I thought that perhaps it would work,
            since I had a simple example that does everything in main,
            but it also crashed.<o:p></o:p></p>
          <p class="MsoNormal">Then I decided to play an alternating
            game where I trimmed the string until it stopped crashing,
            then lowered Xss by 64k and repeated.<o:p></o:p></p>
          <p class="MsoNormal">Eventually, I got it crashing with a call
            stack well over 500 calls deep on a string less than a 128
            characters long.<o:p></o:p></p>
          <p class="MsoNormal">(The string was not hand-crafted; it was
            simply a prefix of the original string that caused the first
            crash I tracked down.)<o:p></o:p></p>
          <p class="MsoNormal">The string in question had a mere five
            tokens, which is to say that it had just four commas.<o:p></o:p></p>
          <p class="MsoNormal">It had no open or close parenthesis, so
            the entire negative lookahead assertion served as a giant
            no-op, at least when it wasn’t crashing.<o:p></o:p></p>
          <p class="MsoNormal">(Technically, the stack usage is linear
            in the length of the input AFTER the first comma, but the
            first comma was pretty early.)<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">Sorry if this email is poorly organized;
            I’ve already spent way too many hours on it (not even
            counting the debugging that prompted it) and I need to get
            some sleep now.<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">If anyone actually reads all or most of
            this, thank you.<o:p></o:p></p>
          <p class="MsoNormal">Mark.<o:p></o:p></p>
          <p class="MsoNormal"> <o:p></o:p></p>
          <p class="MsoNormal">P.S. if anyone actually responds, thank
            you even more.<o:p></o:p></p>
          <p>This message is for information purposes only. It is not a
            recommendation, advice, offer or solicitation to buy or sell
            a product or service, nor an official confirmation of any
            transaction. It is directed at persons who are professionals
            and is intended for the recipient(s) only. It is not
            directed at retail customers. This message is subject to the
            terms at:
            <a href="https://clicktime.symantec.com/15t69jbyHVwykk1KPBVA2?h=WSydRJ-8a9jEVWGSLyCrdLEU7Xfx-K-gu16DAstEYWQ=&u=https://www.ib.barclays/disclosures/web-and-email-disclaimer.html" moz-do-not-send="true">
https://www.ib.barclays/disclosures/web-and-email-disclaimer.html</a>. <o:p></o:p></p>
          <p>For important disclosures, please see: <a href="https://clicktime.symantec.com/15t64uQgptGPLoBPqd61Q?h=sYkJo73WS5C5wTtskVoUQEfn7gI-sb4yDI0khVoYK3Q=&u=https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html" moz-do-not-send="true">
https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html</a>
            regarding marketing commentary from Barclays Sales and/or
            Trading desks, who are active market participants;
            <a href="https://clicktime.symantec.com/15t5pQpqT3Dc6xhdCwtZY?h=qVJHSoTdp0pI-_4TT9h4U49uHhqWqUQdMGYEdhG-Ouo=&u=https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html" moz-do-not-send="true">
https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html</a>
            regarding our standard terms for Barclays Investment Bank
            where we trade with you in principal-to-principal wholesale
            markets transactions; and in respect to Barclays Research,
            including disclosures relating to specific issuers, see: <a href="https://clicktime.symantec.com/15t5ZvEz5CAps8DraGh7g?h=87QBG12g6Fm-478KIe1pp-nBD10MhX6JgAq8TwQi770=&u=http://publicresearch.barclays.com" moz-do-not-send="true">
              http://publicresearch.barclays.com</a>.<br>
__________________________________________________________________________________
            <br>
            If you are incorporated or operating in Australia, read
            these important disclosures:
            <a href="https://clicktime.symantec.com/15t5uF27ueuCWuXYkWHiA?h=GPXVMoOv512jLvxDhIJnWdewKcbTe5uGye3MLfO8Uxc=&u=https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html" moz-do-not-send="true">
https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html</a>.<br>
__________________________________________________________________________________<br>
            For more details about how we use personal information, see
            our privacy notice: <a href="https://clicktime.symantec.com/15t5z5DQNGanvrMUJ4grn?h=zIClmLbPkrAGRja2m5HovRZhDKBBGmDTQHvE9kjAkxQ=&u=https://www.ib.barclays/disclosures/personal-information-use.html" moz-do-not-send="true">
https://www.ib.barclays/disclosures/personal-information-use.html</a>. <br>
__________________________________________________________________________________<o:p></o:p></p>
        </blockquote>
        <p class="MsoNormal"><span style="mso-ligatures:none"><o:p> </o:p></span></p>
      </div>
      <p><span style="mso-ansi-language: EN-US" lang="EN-US">This
          message is for information purposes only. It is not a
          recommendation, advice, offer or solicitation to buy or sell a
          product or service, nor an official confirmation of any
          transaction. It is directed at persons who are professionals
          and is intended for the recipient(s) only. It is not directed
          at retail customers. This message is subject to the terms at:
          <a href="https://www.ib.barclays/disclosures/web-and-email-disclaimer.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ib.barclays/disclosures/web-and-email-disclaimer.html</a>.
        </span></p>
      <p><span style="mso-ansi-language: EN-US" lang="EN-US">For
          important disclosures, please see: <a href="https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ib.barclays/disclosures/sales-and-trading-disclaimer.html</a>
          regarding marketing commentary from Barclays Sales and/or
          Trading desks, who are active market participants; <a href="https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ib.barclays/disclosures/barclays-global-markets-disclosures.html</a>
          regarding our standard terms for Barclays Investment Bank
          where we trade with you in principal-to-principal wholesale
          markets transactions; and in respect to Barclays Research,
          including disclosures relating to specific issuers, see: <a href="http://publicresearch.barclays.com" moz-do-not-send="true" class="moz-txt-link-freetext">http://publicresearch.barclays.com</a>.<br>
__________________________________________________________________________________
          <br>
          If you are incorporated or operating in Australia, read these
          important disclosures: <a href="https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ib.barclays/disclosures/important-disclosures-asia-pacific.html</a>.<br>
__________________________________________________________________________________<br>
          For more details about how we use personal information, see
          our privacy notice: <a href="https://www.ib.barclays/disclosures/personal-information-use.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://www.ib.barclays/disclosures/personal-information-use.html</a>.
          <br>
__________________________________________________________________________________<br>
        </span></p>
    </blockquote>
    <br>
  </body>
</html>