Mailing-List: contact notifications-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@groovy.apache.org
Date: Wed, 20 Sep 2017 20:40:00 +0000 (UTC)
From: "Jochen Theodorou (JIRA)" <jira@apache.org>
To: notifications@groovy.apache.org
Message-ID: <JIRA.13103352.1505852970000.160758.1505940000521@Atlassian.JIRA>
In-Reply-To: <JIRA.13103352.1505852970000@Atlassian.JIRA>
References: <JIRA.13103352.1505852970000@Atlassian.JIRA> <JIRA.13103352.1505852970611@jira-lw-us.apache.org>
Subject: [jira] [Commented] (GROOVY-8324) Enabling groovy.indy.logging can
 lead to stack overflows
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Wed, 20 Sep 2017 20:40:06 -0000


    [ https://issues.apache.org/jira/browse/GROOVY-8324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16173788#comment-16173788 ] 

Jochen Theodorou commented on GROOVY-8324:
------------------------------------------

first time you mention @ToString. This is a strong indicator for the printing of the arguments in the logging. "this" is the first argument, thus if this.toString is done by invokedynamic, it will lead to an stack overflow. Which meand org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.<init>(Selector.java:499) needs a fix for the arguments. If you want to really get to the bottom if this I suggest you remove parts from the logging message in this line and see which is causing it. My bet is now on the arguments

> Enabling groovy.indy.logging can lead to stack overflows
> --------------------------------------------------------
>
>                 Key: GROOVY-8324
>                 URL: https://issues.apache.org/jira/browse/GROOVY-8324
>             Project: Groovy
>          Issue Type: Bug
>    Affects Versions: 2.4.12
>            Reporter: Matt Whipple
>            Priority: Minor
>              Labels: invokedynamic
>
> Still digging through this a bit more, but while trying to diagnose performance issues I enabled indy logging which led to:
> {noformat}
> ! Caused by: java.lang.StackOverflowError: null
> ! at java.lang.Class.getEnclosingMethodInfo(Class.java:1072)
> ! at java.lang.Class.getEnclosingClass(Class.java:1272)
> ! at java.lang.Class.getSimpleBinaryName(Class.java:1443)
> ! at java.lang.Class.getSimpleName(Class.java:1309)
> ! at java.lang.invoke.MethodType.toString(MethodType.java:797)
> ! at java.lang.String.valueOf(String.java:2982)                        <--- Loops back to here
> ! at java.lang.StringBuilder.append(StringBuilder.java:131)
> ! at org.codehaus.groovy.vmplugin.v7.Selector$MethodSelector.<init>(Selector.java:488)
> ! at org.codehaus.groovy.vmplugin.v7.Selector.getSelector(Selector.java:98)
> ! at org.codehaus.groovy.vmplugin.v7.IndyInterface.selectMethod(IndyInterface.java:227)
> ! at MyDomainClass.toString(MyDomainClass.groovy)
> {noformat}
> The domain class itself stringifies without issue, changing the class to use {{@CompileStatic}} seems to have resolved this issue. It might be nice if that specific log message could be toggled independently of the others to try to avoid the possibility of blowing up while attempting to troubleshooting. 
> {noformat}
> java version "1.8.0_45"
> Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
> Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)
> {noformat}


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)