Details

    • Type: Bug
    • Status: CLOSED
    • Priority: Major
    • Resolution: Out of Scope
    • Affects Version/s: Scala 2.9.2
    • Fix Version/s: None
    • Labels:
      None
    • Environment:

      Scala code runner version 2.9.0.1 – Copyright 2002-2011, LAMP/EPFL

      java version "1.6.0_26"
      Java(TM) SE Runtime Environment (build 1.6.0_26-b03-383-11A511)
      Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02-383, mixed mode)

      Description

      JSON.parseFull or parseRaw randomly fails with NPE. In order to get the stacktrace, one must use -Xint flag. It works fine most of the time and randomly fails. When I run a simple script that parses JSON.parseFull("

      {\"hello\": \"dude\"}

      "), when run in a loop 10K times, it fails a few times during the run (again, randomly). Below is the stacktrace...

      java.lang.NullPointerException: null
      at scala.util.parsing.combinator.Parsers$NoSuccess.<init>(Parsers.scala:132) ~[scala-library.jar:na]
      at scala.util.parsing.combinator.Parsers$Failure.<init>(Parsers.scala:159) ~[scala-library.jar:na]
      at scala.util.parsing.combinator.Parsers$$anonfun$acceptIf$1.apply(Parsers.scala:499) ~[scala-library.jar:na]
      ...

        Attachments

          Issue Links

            Activity

            Hide
            davidcarltonsumo David Carlton added a comment -

            Ah, thanks for the insight, that could be related.

            Show
            davidcarltonsumo David Carlton added a comment - Ah, thanks for the insight, that could be related.
            Hide
            davidcarltonsumo David Carlton added a comment -

            I managed to reproduce my problem with an isolated test case; given that my problem is different from the problem that this bug was filed about, I figured the best thing to do would be to file a new bug, so I created SI-9010 with reproduction steps.

            Show
            davidcarltonsumo David Carlton added a comment - I managed to reproduce my problem with an isolated test case; given that my problem is different from the problem that this bug was filed about, I figured the best thing to do would be to file a new bug, so I created SI-9010 with reproduction steps.
            Hide
            jenshalm Jens Halm added a comment - - edited

            I'm not sure it is a good idea to create a new ticket. Yes, the title of this ticket is misleading, but most of the discussion in this ticket already relates to the leak and not the original problem. The new ticket suggests that it is something that requires new investigations and might lead to someone overlooking this extensive discussion.

            The problem is already fully understood. From the source code it is very obvious that the ThreadLocal will leak when you don't use the phrase parser as the top level parser.

            I already suggested a workaround that would minimize the problem sometime ago (see older comments). It would reduce the leak from having the entire parser hierarchy including the full input string hanging in the ThreadLocal to only leaking a None per ThreadLocal which is comparably harmless.

            I just never got around to implementing this improvement because I never got feedback from project maintainers whether they'd accept such a fix and then it somehow fell from my radar.

            Show
            jenshalm Jens Halm added a comment - - edited I'm not sure it is a good idea to create a new ticket. Yes, the title of this ticket is misleading, but most of the discussion in this ticket already relates to the leak and not the original problem. The new ticket suggests that it is something that requires new investigations and might lead to someone overlooking this extensive discussion. The problem is already fully understood. From the source code it is very obvious that the ThreadLocal will leak when you don't use the phrase parser as the top level parser. I already suggested a workaround that would minimize the problem sometime ago (see older comments). It would reduce the leak from having the entire parser hierarchy including the full input string hanging in the ThreadLocal to only leaking a None per ThreadLocal which is comparably harmless. I just never got around to implementing this improvement because I never got feedback from project maintainers whether they'd accept such a fix and then it somehow fell from my radar.
            Hide
            sethtisue Seth Tisue added a comment -

            The parser combinators library is now community-maintained. Issues with it are now tracked at https://github.com/scala/scala-parser-combinators/issues/61 instead of here in the Scala JIRA.

            Interested community members: if you consider this issue significant, feel free to open a new issue for it on GitHub, with links in both directions.

            Show
            sethtisue Seth Tisue added a comment - The parser combinators library is now community-maintained. Issues with it are now tracked at https://github.com/scala/scala-parser-combinators/issues/61 instead of here in the Scala JIRA. Interested community members: if you consider this issue significant, feel free to open a new issue for it on GitHub, with links in both directions.
            Hide
            sethtisue Seth Tisue added a comment -

            there is a PR for this, needing review, at https://github.com/scala/scala-parser-combinators/pull/59

            Show
            sethtisue Seth Tisue added a comment - there is a PR for this, needing review, at https://github.com/scala/scala-parser-combinators/pull/59

              People

              • Assignee:
                Unassigned
                Reporter:
                isterin Ilya Sterin
              • Votes:
                15 Vote for this issue
                Watchers:
                26 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: